Vom Sicherheitsalphabet: CIA, KGB, DIE, CAP

Kaum ein anderer Begriffsblock der Informatik wirkt nach aussen so trivial und entfaltet nach innen eine derart harte Sprengkraft wie das klassische Sicherheitsalphabet. Drei Buchstaben hier, drei dort, ein Theorem aus der verteilten Systemtheorie, dazu ein paar wohlklingende Designparolen, und schon entsteht beim unbedarften Leser der Eindruck, es handle sich um ein bisschen Terminologie für Folienpräsentationen. Wer ernsthaft Systeme baut, weiss, dass diese Abkürzungen in Wirklichkeit Kurzschreibweisen für brutale Zwänge sind, aus denen sich niemand herausmogeln kann.

In meiner eigenen Arbeit haben sich ein paar dieser Abkürzungen zu dauernden Begleitern entwickelt: die CIA-Triade1 2 3, in meiner Lesart mit Authenticity statt Availability; das gerne in deutscher Fassung verwendete KGB-Schema: Kommunikationssicherheit, gewährleistete Übertragung, Beweisbarkeit; das Architekturmantra DIE4; das allgegenwärtige CAP-Theorem5; und als verbindendes Element die Idempotenz6 als operativer Schutzmechanismus gegen die Unbill verteilter Systeme. Dieser Text dient mir als konzeptionelle Grundierung: ein sortiertes Sicherheitsalphabet, auf das ich mich in nachfolgenden Analysen beziehen kann.

Dabei geht es ausdrücklich nicht um die hundertste populärwissenschaftliche Nacherzählung eines Wikipedia-Artikels, sondern um eine saubere Begriffsökologie, eine klare innere Ordnung und die Einbettung dieser Konzepte in reale Architekturentscheidungen. Denn an den Berührungspunkten zwischen Kryptographie, Betriebsführung und Verteiltssystemtheorie entscheidet sich, ob ein System unter Last und Angriff noch trägt oder in sich zusammenklappt.

Im Folgenden spanne ich den Bogen von den Schutzzielen über die Kommunikationsschicht und die Infrastruktur hin zur Systemgrenze, an der das CAP-Theorem wartet, und setze Idempotenz dort ein, wo sie hingehört: als praktisches Werkzeug, das es erlaubt, mit diesen Zwängen zu leben, statt an ihnen zu zerbrechen.

CIA

Die klassische Informationssicherheitsliteratur beschreibt die CIA-Triade seit Jahrzehnten als Dreiklang aus Confidentiality, Integrity und Availability. Vertraulichkeit, Integrität, Verfügbarkeit, so liest man es in praktisch jedem einführenden Text, ob in Standardwerken von Herstellern, NIST-Publikationen oder allgemeinen Nachschlagewerken zu Informationssicherheit.7

Vertraulichkeit adressiert die Frage, wer Daten überhaupt lesen darf. Integrität beantwortet die Frage, ob Daten unbemerkt verändert wurden. Verfügbarkeit schliesslich beschreibt, ob ein System rechtzeitig und in ausreichendem Umfang nutzbar ist. Diese Triade dient als Orientierungsrahmen für Sicherheitsrichtlinien, Risikoanalysen und technische Massnahmen und bildet das, was man ohne Übertreibung als Kleinstbaustein des gesamten Informationssicherheitsdiskurses bezeichnen kann.8

Ich selbst habe die CIA-Triade in einer leicht anderen Tradition gelernt und übernommen: C steht für Confidentiality, I für Integrity, A für Authenticity. Verfügbarkeit taucht bei mir nicht auf dieser ersten Ebene auf, weil sie aus meiner Sicht primär eine Eigenschaft der Architektur und des Betriebs ist, nicht der Kryptographie. Authenticity hingegen entscheidet, ob ich überhaupt weiss, mit wem ich es zu tun habe, und ob eine Nachricht wirklich von der behaupteten Quelle stammt.

Die Verschiebung wirkt auf den ersten Blick marginal, im Detail verändert sie jedoch den Schwerpunkt. Ein System, das konsequent verschlüsselt, signiert und Identitäten sauber prüft, erreicht Vertraulichkeit, Integrität und Authentizität, aber es ist damit noch lange nicht verfügbar. Die klassische CIA-Triade mischt hier konzeptionell zwei Ebenen: Schutzziele, die mit Kryptographie und Protokolldesign erreichbar sind, und ein Ziel, das von Redundanz, Resilienz und Betrieb abhängt.

Um diese Diskrepanz aufzulösen, arbeite ich mit einer erweiterten Fassung, die man als CIA(AN) notieren kann: Confidentiality, Integrity, Authenticity, ergänzt um Availability und Non-Repudiation. Diese Fünfergruppe deckt sich im Ergebnis mit dem, was manche Autoren als fünf Säulen der Informationssicherheit beschreiben: Vertraulichkeit, Integrität, Verfügbarkeit, Authentizität und Nicht-Abstreitbarkeit.9

Authentizität und Nicht-Abstreitbarkeit hängen eng zusammen, dürfen aber nicht vermischt werden. Authenticity beantwortet: „Wer ist das?“ Non-Repudiation beantwortet: „Wer hat wann was getan, und kann er das später glaubhaft leugnen?“ NIST10 11 formuliert das treffend, indem Authentizität und Nicht-Abstreitbarkeit zum Teilbereich der Integrität gezählt werden, ohne sie vollständig mit dieser gleichzusetzen.12

Für diesen Text halte ich die Terminologie explizit fest:

Wenn ich CIA sage, meine ich Confidentiality, Integrity, Authenticity. Availability und Non-Repudiation stehen als zusätzliche Schutzziele daneben und ergeben zusammen CIA(AN).

CIA(AN)

Diese Fünfergruppe markiert für mich die abstrakte Zielschicht: Hier geht es um das, was ein System aus Sicht von Angreifern, Betreibern und Betroffenen gewährleisten soll.

Vertraulichkeit erklärt, ob jemand mitlesen kann. Integrität erklärt, ob jemand unbemerkt hineingreifen kann. Authentizität erklärt, ob Identitäten belastbar sind. Verfügbarkeit erklärt, ob das System überhaupt zur Verfügung steht. Non-Repudiation erklärt, ob sich Aktionen im Nachhinein zuordnen und beweissicher nachvollziehen lassen.

CIA(AN) bildet damit eine Art normativen Projektionsraum. Auf dieser Ebene existieren noch keine Datenbanken, keine Netzsegmente, keine Container-Orchestrierungen, sondern lediglich Schutzziele, die später von konkreten technischen und organisatorischen Massnahmen realisiert werden sollen.

KGB

Wo CIA(AN) den Gesamtzustand eines Systems adressiert, fokussiert das KGB-Schema auf den Kommunikationsvorgang, also den Weg von Daten von A nach B.

K steht für Kommunikationssicherheit in einem umfassenden Sinn: Ende-zu-Ende-Verschlüsselung, Schutz vor Man-in-the-Middle-Angriffen13, Schutz vor Replay14, Schutz vor Downgrade-Attacken15, saubere Aushandlung kryptographischer Parameter. Ohne K bricht Vertraulichkeit auf der Leitung zusammen, und Integrität wird illusorisch.

G steht für gewährleistete Übertragung. Hier taucht das Thema Verfügbarkeit in konkretisierter Form wieder auf: Nachrichten sollen zugestellt werden, trotz Netzproblemen, Paketverlusten, Defekten und temporären Ausfällen. Dazu braucht es Queues, Retries, Timeouts, Routing-Strategien und Monitoring.

B steht für Beweisbarkeit. Darunter verstehe ich die Fähigkeit, eine konkrete Kommunikationshandlung später nachvollziehen zu können: Wer hat wann welche Nachricht erzeugt, signiert, übertragen, bestätigt, archiviert. Digitale Signaturen, Zeitstempel, manipulationssichere Logs und eine belastbare PKI16 gehören in diesen Bereich.

KGB ist damit keine Konkurrenz zu CIA(AN), sondern eine Perspektivverschiebung: dieselben Schutzziele, aber projiziert auf den Kommunikationskanal und seine forensische Nachvollziehbarkeit.

DIE

Der dritte Baustein, den ich mir angewöhnt habe, konsequent mitzudenken, trägt das Kürzel DIE: Distributed, Immutable, Ephemeral.

Distributed beschreibt die Verteilung von Diensten und Daten über mehrere Knoten, Standorte oder Zonen. Ohne Verteilung bleibt jeder Ausfall ein Totalausfall. Mit Verteilung entsteht die Chance auf Resilienz, allerdings um den Preis zusätzlicher Komplexität und neuer Fehlermodi.

Immutable bedeutet, dass Systemzustände nicht durch manuelle Kleinstreparaturen am laufenden Objekt verändert werden, sondern durch reproduzierbare Artefakte: Images, Container, deklarative Konfigurationen. Änderungen erfolgen durch Neubau und Rollout, nicht durch Basteln per SSH.

Ephemeral bedeutet, dass Instanzen grundsätzlich als vergänglich gedacht werden. Sie dürfen jederzeit sterben, ersetzt werden, horizontal skaliert werden. Langfristige Identitäten werden nicht an einzelne Maschinen geknüpft, sondern an Rollen, Dienste, Konfigurationen.

DIE ist damit eine sehr konkrete Antwort auf Availability und auf Teile der Integrität. Wer verteilte, unveränderliche, vergängliche Infrastruktur baut, erschwert eine ganze Klasse von Angriffen und reduziert die Fehleranfälligkeit von Betrieb. Die Kehrseite: verteilte Systeme sind anfällig für Netzpartitionen, und genau dort beginnt das Reich von CAP.

CAP

Das CAP-Theorem, von Eric Brewer ursprünglich als Conjecture formuliert und durch Gilbert und Lynch formalisiert, ist eines jener Resultate, die wie eine banale Marketingfolie aussehen und bei näherem Hinsehen zu einem harten Limit werden.17

In der üblichen Fassung lautet es: Ein verteiltes Datensystem kann unter Netzpartitionierung nicht gleichzeitig strenge Consistency und strenge Availability garantieren, Partition Tolerance ist in realen Netzen nicht verhandelbar. Man kann also bei auftretender Partition nur zwischen Konsistenz und Verfügbarkeit wählen.18

Consistency bedeutet hier, dass jede erfolgreiche Leseoperation den zuletzt bestätigten Schreibvorgang sieht oder einen Fehler meldet. Availability bedeutet, dass jede Anfrage an einen nicht abgestürzten Knoten eine Antwort erhält, unabhängig davon, ob sie den allerneusten Stand reflektiert. Partition Tolerance bedeutet, dass das System trotz verlorener oder verzögerter Nachrichten zwischen Knoten weiterarbeitet.19

CAP zwingt also zu expliziten Entscheidungen. Wer glaubt, sich elegant aus dieser Wahl heraushalten zu können, indem er von „hoher Verfügbarkeit bei voller Konsistenz“ fabuliert, betreibt Selbsttäuschung.

Idempotenz

Die letzte Komponente meines Sicherheitsalphabets stammt aus der Mathematik und aus der theoretischen Informatik: Idempotenz.

Eine Operation f heisst idempotent, wenn gilt:

\(
{
f(f(x)) = f(x)
}
\)

In der Informatik überträgt man diesen Begriff auf Funktionen, Prozeduren oder Dienste, die mehrfach angewendet werden können, ohne dass sich der Systemzustand über die erste Anwendung hinaus verändert.

Eine idempotente HTTP-PUT-Operation, die eine Ressource auf einen bestimmten Wert setzt, kann man im Fehlerfall beliebig oft wiederholen, ohne dass sich irgendetwas „aufsummiert“. Eine Prozedur „setze Flag X auf wahr“ ist idempotent, eine Prozedur „invertiere Flag X“ ist es nicht.20

Meine Erfahrung mit verteilten Systemen, Netzwerkproblemen und fehleranfälligen Infrastrukturen ist brutal einfach: Ohne Idempotenz wird CAP zum Minenfeld. Mit Idempotenz lassen sich Retries, Wiederaufnahmen, Kompensationslogik und ausfalltolerante Protokolle konstruieren, die trotz Partitionen und Teilausfällen eine brauchbare Konsistenz behalten.

Zwischenfazit

In dieser Begriffsökologie sitzen CIA(AN) als Schutzziele oben, KGB beschreibt den Kommunikationsblick, DIE modelliert die Infrastruktur, CAP markiert die theoretische Systemgrenze, und Idempotenz liefert praktische Werkzeuge, um unter diesen Grenzen leben zu können.

Schutzziele: Was ein System leisten soll

Ein vernünftiger Einstieg beginnt bei der Frage, was überhaupt geschützt werden soll. CIA(AN) liefert hier einen kompakten, aber durchaus anspruchsvollen Zielkatalog.

Vertraulichkeit verlangt, dass Unbefugte keinen Zugriff auf Inhalte erhalten, weder beim Speichern noch beim Transport noch in Zwischenspeichern. Das ist mehr als Verschlüsselung: Es umfasst Zugriffskontrolle, Rollenmodelle, physische Sicherheitsmassnahmen und organisatorische Regeln.

Integrität verlangt, dass Daten nicht unbemerkt verändert werden. Hashfunktionen21, Message Authentication Codes22, digitale Signaturen23, Merkle-Bäume24, Prüfsummen25 in Protokollen, all das dient letztlich diesem Zweck.

Authentizität verlangt, dass Identitäten26 und Objekte eindeutig und überprüfbar sind. Zertifikate27, SSH-Hostkeys, Hardware-Tokens, starke Authentisierung28, signierte Artefakte und ein durchdachtes Identity-Management29 gehören in diesen Bereich.

Verfügbarkeit verlangt, dass Dienste und Daten zur richtigen Zeit in brauchbarer Qualität bereitstehen. Redundanz30, Loadbalancing31, Monitoring, DDoS-Schutz32, Failover-Mechanismen33, Notfallpläne34, das gesamte Thema „High Availability“35 wird hier verortet.

Non-Repudiation verlangt, dass sich Handlungen im Nachhinein nicht glaubhaft abstreiten lassen. Digitale Signaturen mit Schlüsselmanagement, Zeitstempel, Audit-Logs, unveränderliche Journale, gegebenenfalls externe Zeitquellen und notarielle Dienste sind Werkzeuge hierfür.36

Zwischenfazit

Schutzziele sind damit weder rein technisch noch rein organisatorisch. Sie liegen an der Schnittstelle zwischen Kryptographie, Architektur, Recht, Governance und Betrieb. Sie definieren, was akzeptabel ist und was nicht. Wie diese Ziele umgesetzt werden, ist dann eine Frage der darunter liegenden Ebenen.

Schutzziele auf der Leitung

Sobald Daten eine Leitung betreten, verdichten sich die Schutzziele zu konkreten Protokoll- und Designfragen.

Kommunikationssicherheit, der erste Bestandteil des KGB-Schemas, verlangt, dass Inhalte unterwegs nicht mitgelesen, nicht unbemerkt verändert und nicht ohne Wissen der Endpunkte umgeleitet werden können. Ende-zu-Ende-Verschlüsselung37, Forward Secrecy38, saubere Zertifikatsvalidierung, Vermeidung von Klartext-Fallbacks, Schutz vor Downgrade-Attacken und ein bewusst gestalteter Cipher-Suite-Katalog39 40 gehören in diesen Bereich.

Gewährleistete Übertragung konzentriert sich auf die Robustheit des Transports. Pakete gehen verloren, Verbindungen brechen ab, DNS löst falsch auf, Routen kippen. Ein System mit ernst gemeinter Gewährleistung arbeitet mit Retries, Exponential Backoff41, dedizierten Queues, Dead-Letter-Mechanismen42 43 und Monitoring, das solche Probleme nicht nur anzeigt, sondern automatisiert Gegenmassnahmen auslöst.

Beweisbarkeit schliesslich hebt die Kommunikation aus dem flüchtigen Moment in den forensischen Raum. Wer bestimmte Nachrichten signiert, Zeitpunkt und Kontext protokolliert, Logs manipulationsresistent archiviert und nachvollziehbare Schlüssellebenszyklen pflegt, kann Vorgänge später rekonstruieren. Ohne diese Schicht bleibt Non-Repudiation eine Behauptung.

Interessant wird KGB dort, wo technische und rechtliche Dimensionen sich treffen: Eine E-Mail mit DKIM-Signatur44, SPF-Policy45 und streng validiertem TLS-Transport erfüllt ein deutlich anderes Beweisniveau als eine unverschlüsselte Mail ohne Signatur über beliebige Relays. Genau hier entscheidet sich, ob ein Kommunikationssystem lediglich „funktioniert“ oder ob es vertrauenswürdig ist.

Wie Infrastruktur gebaut sein muss

Schutzziele und Kommunikationsschicht definieren, was erreicht werden soll. DIE beschreibt, wie Infrastruktur beschaffen sein sollte, damit diese Ziele in realen Umgebungen nicht an der ersten Störung zerschellen.

Verteilung schafft räumliche und logische Redundanz. Mehrere Rechenzentren, mehrere Instanzen pro Dienst, unabhängige Netzwerkpfade, getrennte Verwaltungsdomänen, replizierte Datenbestände: all das erhöht die Chance, dass ein lokaler Ausfall nicht das Gesamtsystem niederreisst. Gleichzeitig entstehen neue Fragen: Wie werden Daten repliziert, wie wird Konfliktlösung implementiert, wie wird mit Netzpartitionen umgegangen.

Unveränderlichkeit richtet sich gegen Konfigurationsdrift, die niemand mehr versteht, aber niemand abschalten will. Wer Zustände über Images und deklarative Konfigurationen erzeugt und Änderungen nur durch Neubau dieser Artefakte zulässt, reduziert die Zahl heimlicher Abweichungen und dokumentiert faktisch jeden Schritt. Immutable Infrastructure ist damit eine Art technische Hygienevorschrift.

Vergänglichkeit nimmt der einzelnen Instanz ihren Nimbus der Unantastbarkeit. Wenn Services bewusst als kurzlebig gedacht werden, kann eine orchestrierende Schicht sie jederzeit ersetzen, horizontal erweitern oder im Fehlerfall entfernen. Diese Ephemeralität ist Grundvoraussetzung für echtes Auto-Healing46 und skalierbare Systeme.

DIE ist damit eine direkte Antwort auf das Schutzziel Availability und eine indirekte Antwort auf Integrität und Non-Repudiation. Verteilt, unveränderlich, vergänglich heisst: kein verstecktes Herumgehacke auf produktiven Systemen, keine undokumentierten „Patch-Aktionen um Mitternacht“, sondern nachvollziehbare, reproduzierbare Zustände.

Zwischenfazit

Die Kehrseite ist offensichtlich: In dem Moment, in dem Systeme verteilt werden, tritt das CAP-Theorem auf die Bühne. Verteilte Datenhaltung ohne Netzpartitionen ist Fiktion. Damit verschiebt sich die Fragestellung: Nicht „ob“ CAP relevant ist, sondern „wie“ man mit diesen Zwängen umgeht.

Warum sich verteilte Systeme nicht beliebig verbiegen lassen

CAP ist als formales Resultat entwaffnend schlicht und gleichzeitig in der Praxis erstaunlich missverstanden. Die formal bewiesene Aussage lautet, stark verkürzt: In einem verteilten Datensystem, das Netzpartitionen tolerieren soll, kann man im Partitionierungsfall nicht gleichzeitig strenge Konsistenz und strenge Verfügbarkeit garantieren.47

Wird eine Partition angenommen, muss man sich entscheiden. Entweder wird jeder Zugriff, der nicht sicher den aktuellsten Zustand liefern kann, verweigert oder mit Fehler beantwortet. Dann opfert man Availability zugunsten von Consistency. Oder man beantwortet jede Anfrage mit dem, was lokal bekannt ist, akzeptiert also potenziell divergierende Zustände. Dann opfert man Consistency zugunsten von Availability.48

Die Definition von Consistency im CAP-Kontext unterscheidet sich dabei deutlich von ACID-Konsistenz in relationalen Datenbanken.49 Es geht nicht um Invarianten auf Datenebene, sondern um die Sichtbarkeit von Operationen im verteilten System: Jede erfolgreiche Leseoperation sieht entweder den letzten erfolgreichen Schreibvorgang oder scheitert.50

Partition Tolerance ist in realen Netzwerken keine Option, die man „abwählen“ kann, sondern eine schlichte Folge der Realität. Pakete gehen verloren, Switches sterben, Glasfasern werden durchtrennt, Routen flappen. Distributed ohne Partition Tolerance existiert nur auf PowerPoint-Slides.51

Die Konsequenz ist unbequem: Jedes ernsthaft verteilte System trifft an irgend einem Punkt Entscheidungen, die seine Position auf der Achse zwischen CP-Verhalten (Consistency und Partition Tolerance) und AP-Verhalten (Availability und Partition Tolerance) festlegen. Wer behauptet, ein System sei „gleichzeitig CA“, ignoriert Partitionen oder definiert sie weg. Genau an dieser Stelle setzen spätere Verfeinerungen wie PACELC52 und kritische Auseinandersetzungen mit dem Nutzungskontext von CAP an.53

Zwischenfazit

Für meine Zwecke genügt an dieser Stelle die pragmatische Lesart: In dem Moment, in dem ich Dienste verteile, muss ich explizit festlegen, wie sie sich im Fehlerfall verhalten. Zurückhaltendes CP-Verhalten mit harter Konsistenz und möglichem Ausfall, oder grosszügigeres AP-Verhalten mit stets verfügbaren Antworten, die bei Wiedervereinigung der Partition Konfliktlösung erfordern.

Idempotenz als Brücke zwischen Theorie und Betrieb

Idempotenz stammt ursprünglich aus der Algebra. Ein Element e in einer algebraischen Struktur heisst idempotent, wenn e mit sich selbst verknüpft wieder e ergibt. Benjamin Peirce hat den Begriff im 19. Jahrhundert geprägt, um Elemente zu beschreiben, die unter Potenzierung stabil bleiben.54

Die Informatik hat diesen Begriff übernommen und auf Operationen, Funktionen und Prozeduren übertragen. Idempotent ist eine Operation dann, wenn mehrfache Anwendung auf denselben Ausgangszustand keinen zusätzlichen Effekt über den ersten Aufruf hinaus erzeugt.

Diese Definition lässt sich auf unterschiedliche Kontexte anwenden. In funktionalen Sprachen spricht man von idempotenten Funktionen, in imperativen Sprachen von idempotenten Prozeduren mit Seiteneffekten, im Netzwerkdesign von idempotenten Protokolloperationen.

Entscheidend ist die praktische Folgerung: Eine idempotente Operation kann uneingeschränkt wiederholt werden, ohne dass der Systemzustand unkontrolliert driftet.

Ein paar Beispiele machen den abstrakten Begriff greifbar.

Die HTTP-Spezifikation deklariert Methoden wie GET, PUT und DELETE als idempotent, sofern der Server korrekt implementiert ist. Ein GET, der Ressourcen unverändert liest, kann beliebig oft wiederholt werden. Ein PUT, der eine Ressource auf einen bestimmten Wert setzt, kann ebenso beliebig oft wiederholt werden, solange der Server nicht intern noch zusätzliche Seiteneffekte einbaut. Ein DELETE, der eine Ressource entfernt, ist im Erfolgsfall idempotent, weil weitere DELETE-Aufrufe denselben Zustand „nicht vorhanden“ vorfinden.55

Ein typisches Gegenbeispiel wäre eine Operation „überweise 100 CHF von Konto A nach Konto B“. Wird dieser Aufruf aufgrund eines vermeintlichen Timeouts wiederholt, ohne dass Idempotenz sichergestellt ist, erfolgt die Überweisung mehrfach. Entsprechende Zahlungssysteme arbeiten daher mit Transfer-IDs, die erlauben, Requests zu erkennen und bei Doppelauftritt zu ignorieren. Die idempotente Operation lautet dann nicht „buche 100 CHF“, sondern „setze Status der Transaktion X auf abgeschlossen“.

Im Konfigurationsmanagement ist der Unterschied noch deutlicher. Ein Shell-Script, das „apt install paket“ aufruft, ist nur dann idempotent, wenn der Paketmanager selbst den Zustand prüft und die Operation wirkungslos bleibt, sobald das Paket installiert ist. Werkzeuge wie Ansible56, Puppet57 oder Salt58 modellieren den gesamten Konfigurationsraum bewusst idempotent: Zustände werden beschrieben, nicht imperative Schrittfolgen, und die Engine sorgt dafür, dass wiederholte Ausführung keinen Schaden anrichtet.

In Event-Streaming-Systemen spricht man von idempotenter Verarbeitung, wenn eine Nachricht, die versehentlich zweimal zugestellt wird, nicht doppelt verbucht wird. Technisch erreicht man dies durch Kombination aus eindeutigen Event-IDs, deduplizierenden Stores oder idempotenten Upsert-Operationen auf Datenbanken.

Idempotenz und CAP-Effekte

An der Schnittstelle zum CAP-Theorem wird Idempotenz zu einem Instrument, das Fehlerfälle entschärft.

Ein verteiltes System unter Partition wird Requests verlieren, verzögern, verdoppeln. Clients sehen Timeouts, Libraries lösen Retries aus, Loadbalancer schieben dieselbe Anfrage an mehrere Backends. In einem nicht idempotenten Design führt das fast zwangsläufig zu Inkonsistenzen: doppelte Buchungen, mehrfach erzeugte Ressourcen, unerwartete Zustandsübergänge.

Idempotente Operationen verwandeln diese Fehlerfälle in harmlose Wiederholungen. Ein Client, der bei vermeintlichem Timeout dieselbe Operation ein zweites Mal absetzt, bringt das System nicht aus dem Tritt, weil der zweite Aufruf am bereits erreichten Zustand abprallt. Das reduziert den Schaden von Partitionen und Interferenzen massiv.

Details entscheiden. Wer beispielsweise in einem AP-artigen System mit Eventual Consistency arbeitet, kann Idempotenz nutzen, um Konflikte auf den granulären Einheiten zu vermindern. Statt „erhöhe Zähler um 1“ wird „setze Zähler auf Wert n mit Versionsvektor v“ modelliert, so dass eine Zusammenführungslogik erkennen kann, welche Operationen bereits berücksichtigt wurden.

Idempotenz ersetzt CAP nicht. Sie verwandelt die harte Entweder-oder-Entscheidung aber in eine Frage, wie stark sich Inkonsistenzen auswirken und wie leicht sie nachträglich bereinigt werden können. Sie wirkt wie ein Dämpfer, der verhindert, dass jeder Fehler im Netz sofort in Geschäftslogik-Katastrophen mündet.

Idempotenz als Grundlage für Automatisierung und Orchestrierung

Aus der Perspektive von Automatisierung und Orchestrierung erhält Idempotenz einen fast schon existenziellen Charakter.

Wer Konfiguration per Hand auf Servern anpasst, kann sich theoretisch mit Skripten behelfen, die nicht idempotent sind. Man führt sie einmal aus, hofft auf Erfolg und repariert im Fehlerfall per SSH. In einer verteilten, unveränderlichen, vergänglichen Infrastruktur funktioniert dieses Muster nicht mehr.

Ein Installer, der ein System vollautomatisch initialisiert, wird mehrfach laufen: im Test, im Staging, in verschiedenen Varianten, bei späteren Migrationen. Ein Orchestrator, der Container startet, skaliert, ersetzt, wird dieselben Ressourcenbeschreibungen immer wieder anwenden. Ein Self-Healing-Mechanismus, der bei Ausfällen Instanzen neu aufbaut, repetiert dieselben Aktionen, oft in unklaren Zwischenzuständen.

Solange diese Prozesse idempotent modelliert sind, stellt das kein Problem dar. Der Installer bringt das System jedes Mal in den beschriebenen Zielzustand. Der Orchestrator kann eine Deployment-Definition beliebig oft anwenden. Der Self-Healing-Mechanismus darf aggressiv nachjustieren.

Sobald Idempotenz fehlt, verwandelt sich dieselbe Umgebung in ein Minenfeld. Jeder Retry birgt die Gefahr, eine noch halbwegs funktionierende Konfiguration in einen inkonsistenten Zustand zu schieben. Jeder spontane Neustart eines Controllers kann Kaskadeneffekte auslösen, die niemand mehr versteht.

DIE als Architekturprinzip setzt implizit Idempotenz voraus. Verteilt, unveränderlich, vergänglich ohne idempotente Operationen ist ein Widerspruch in sich: Die Infrastruktur soll sich laufend selbst neu zusammensetzen, gleichzeitig sind die Aufbau- und Änderungsoperationen nicht gefahrlos wiederholbar.

In meinen eigenen Systemen ist Idempotenz daher eine Designanforderung, kein „Nice to have“. Prozeduren, die Systemzustand verändern, werden so modelliert, dass Wiederholungen im Fehlerfall nicht schaden. Datenmodelle werden so gebaut, dass Upserts59 statt nackter Inserts möglich sind, Zustandsautomaten so, dass illegale Übergänge abgefangen werden.

Schlussfazit

Damit schliesst sich der Kreis zur Ausgangsfrage dieses Textes. CIA(AN) formuliert, welche Schutzziele erreicht werden sollen. KGB beschreibt, wie diese Ziele auf der Leitung sichtbar werden. DIE gibt vor, wie Infrastruktur organisiert sein muss, um diese Ziele im realen Betrieb überhaupt erreichbar zu machen. CAP setzt den Rahmen, der zeigt, welche Kombinationen in verteilten Systemen möglich sind und welche Illusionen man sich sparen kann. Idempotenz schliesslich sorgt dafür, dass die notwendige Komplexität solcher Systeme nicht jedes Mal in unbeherrschbares Chaos umkippt, sobald ein Packet verloren geht oder ein Knoten stirbt.

Wer das Sicherheitsalphabet nur als Folienzierde versteht, wird weiterhin erstaunt auf die Scherben starren, wenn eine grössere Institution nach einem Angriff über Jahre nicht auf die Beine kommt. Wer diese Konzepte dagegen ernsthaft verinnerlicht, kann Systeme so bauen, dass sie Fehler, Angriffe und Ausfälle nicht einfach überstehen, sondern aus ihnen lernen.

Am Schluss bleibt für mich eine recht nüchterne Konsequenz: Diese Begriffe sind nicht akademische Spielereien, sondern verdichtete Erfahrungswerte aus Jahrzehnten Informatik. Wer sich weigert, sie zu lernen und anzuwenden, liefert sich dem Zufall aus.

  1. https://de.wikipedia.org/wiki/Informationssicherheit ↩︎
  2. https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/Zertifizierte-Informationssicherheit/IT-Grundschutzschulung/Online-Kurs-IT-Grundschutz/Lektion_4_Schutzbedarfsfeststellung/4_01_Definitionen.html ↩︎
  3. https://csrc.nist.gov/glossary/term/confidentiality_integrity_availability ↩︎
  4. https://shardsecure.com/blog/updating-cia-triad#:~:text=The%20DIE%20model,the%20needs%20of%20modern%20enterprises. ↩︎
  5. https://en.wikipedia.org/wiki/CAP_theorem ↩︎
  6. https://de.wikipedia.org/wiki/Idempotenz ↩︎
  7. https://www.fortinet.com/resources/cyberglossary/cia-triad ↩︎
  8. https://www.nccoe.nist.gov/publication/1800-26/VolA/index.html ↩︎
  9. https://destcert.com/resources/five-pillars-information-security/ ↩︎
  10. https://www.nist.gov/ ↩︎
  11. https://de.wikipedia.org/wiki/National_Institute_of_Standards_and_Technology ↩︎
  12. https://www.nccoe.nist.gov/publication/1800-26/VolA/index.html ↩︎
  13. https://de.wikipedia.org/wiki/Man-in-the-Middle-Angriff ↩︎
  14. https://de.wikipedia.org/wiki/Replay-Angriff ↩︎
  15. https://de.wikipedia.org/wiki/Downgrade-Angriff ↩︎
  16. https://de.wikipedia.org/wiki/Public-Key-Infrastruktur ↩︎
  17. https://en.wikipedia.org/wiki/CAP_theorem ↩︎
  18. Ebenda. ↩︎
  19. Ebenda. ↩︎
  20. https://www.baeldung.com/cs/idempotent-operations ↩︎
  21. https://de.wikipedia.org/wiki/Hashfunktion ↩︎
  22. https://de.wikipedia.org/wiki/Message_Authentication_Code ↩︎
  23. https://de.wikipedia.org/wiki/Digitale_Signatur ↩︎
  24. https://de.wikipedia.org/wiki/Hash-Baum ↩︎
  25. https://de.wikipedia.org/wiki/Pr%C3%BCfsumme ↩︎
  26. https://de.wikipedia.org/wiki/Elektronische_Identit%C3%A4t ↩︎
  27. https://de.wikipedia.org/wiki/Digitales_Zertifikat ↩︎
  28. https://de.wikipedia.org/wiki/Authentifizierung ↩︎
  29. https://de.wikipedia.org/wiki/Identit%C3%A4tsmanagement ↩︎
  30. https://de.wikipedia.org/wiki/Redundanz_(Technik) ↩︎
  31. https://de.wikipedia.org/wiki/Lastverteilung_(Informatik) ↩︎
  32. https://de.wikipedia.org/wiki/Denial_of_Service ↩︎
  33. https://de.wikipedia.org/wiki/Failover ↩︎
  34. https://de.wikipedia.org/wiki/Betriebliches_Kontinuit%C3%A4tsmanagement ↩︎
  35. https://de.wikipedia.org/wiki/Hochverf%C3%BCgbarkeit ↩︎
  36. https://www.nccoe.nist.gov/publication/1800-26/VolA/index.html ↩︎
  37. https://de.wikipedia.org/wiki/Ende-zu-Ende-Verschl%C3%BCsselung ↩︎
  38. https://de.wikipedia.org/wiki/Perfect_Forward_Secrecy ↩︎
  39. https://de.wikipedia.org/wiki/Cipher_Suite ↩︎
  40. https://ciphersuite.info/ ↩︎
  41. https://en.wikipedia.org/wiki/Exponential_backoff ↩︎
  42. https://aws.amazon.com/de/message-queue/features/ ↩︎
  43. https://www.computerweekly.com/de/tipp/Typische-Fehler-in-ereignisgesteuerten-Architekturen-beheben ↩︎
  44. https://de.wikipedia.org/wiki/DomainKeys_Identified_Mail ↩︎
  45. https://de.wikipedia.org/wiki/Sender_Policy_Framework ↩︎
  46. https://en.wikipedia.org/wiki/Self-management_(computer_science) ↩︎
  47. Siehe Fn. 5 ↩︎
  48. Siehe Fn. 5 ↩︎
  49. https://de.wikipedia.org/wiki/ACID ↩︎
  50. Siehe Fn. 5 ↩︎
  51. Siehe Fn. 5 ↩︎
  52. https://en.wikipedia.org/wiki/PACELC_design_principle ↩︎
  53. Siehe Fn. 5 ↩︎
  54. https://en.wikipedia.org/wiki/Idempotence ↩︎
  55. https://www.baeldung.com/cs/idempotent-operations ↩︎
  56. https://de.wikipedia.org/wiki/Ansible ↩︎
  57. https://de.wikipedia.org/wiki/Puppet_(Software) ↩︎
  58. https://en.wikipedia.org/wiki/Salt_(software) ↩︎
  59. https://wiki.postgresql.org/wiki/UPSERT ↩︎

Categories: Digitalisierung, IT, IT-Security, Kryptographie
Tags: , , ,

You may also like

Search: