# ADR-0003 — Der Bestandsbereich ist verschlüsselt, gelöscht wird über den Schlüssel **Stand:** Angenommen, 20.08.2026 · **Entscheidet:** CIO Thomas Reitz **Bezug:** `ADR-0002` (Startverfahren), Bedienkonzept §4 · **Betrifft:** Ersteinrichtung, Konsolenmenü, Fassungswechsel, Außerbetriebnahme --- ## Worum es geht Ein Gerät steht beim Kunden im Serverraum. Wer bis dorthin kommt, ist freigegeben — der Raum ist die Zugangskontrolle, und so arbeitet jedes Netzwerkgerät. Die Annahme trägt aber genau so lange, wie das Gerät im Haus des Kunden bleibt. **Sie trägt nicht mehr, wenn ein Laufwerk das Haus verlässt:** bei Reparatur, bei Austausch, bei Rückgabe am Vertragsende, bei Entsorgung. Dann entscheidet nicht mehr das Türschloss, sondern allein das, was auf dem Datenträger steht. Die Frage lautet deshalb: **Was gibt ein Laufwerk her, das aus dem Gerät ausgebaut wird?** ## Die Entscheidung **Der Bestandsbereich wird bei der Einrichtung verschlüsselt. Ohne Ausnahme und ohne Schalter.** Er trägt alles, was dem Kunden gehört — Zustandsdatenbank, Wissensspeicher, Vektorindex, Tresor, Protokolle. Genau deshalb ist er auch der richtige und einzige Ort dafür: Die Regel „alles Dauerhafte gehört in den Bestand" macht die Verschlüsselung **eines** Bereichs ausreichend. **Die Wurzeln werden nicht verschlüsselt, sondern auf Unversehrtheit geprüft.** Das ist kein Sparen, sondern eine andere Frage. In den Wurzeln steht unsere ausgelieferte Software — sie ist auf jedem Gerät dieselbe und damit kein Geheimnis. **Vertraulichkeit ist dort kein Thema, Unversehrtheit sehr wohl:** Wer den Datenträger in der Hand hat, könnte die Wurzel verändern und das Gerät startete sie. Dagegen hilft keine Verschlüsselung, sondern eine Prüfung beim Start. Das passt zudem zum A/B-Verfahren: Eine nur lesbare, geprüfte Wurzel ist ohnehin das, was der Fassungswechsel voraussetzt. ## Sichere Löschung heißt Schlüsselvernichtung **Auf Flash-Speichern ist Überschreiben nicht verlässlich.** Die Verschleißverteilung des Laufwerks schreibt an eine andere Stelle, als der Befehl meint; überschriebene Blöcke können physisch erhalten bleiben. Ein Löschlauf, der stundenlang Nullen schreibt, erzeugt vor allem ein gutes Gefühl. **Ist der Bereich verschlüsselt, ist die Löschung die Vernichtung des Schlüssels.** Das dauert Sekunden, ist vollständig und lässt sich belegen. Der Rest ist Rauschen. > Deshalb hängen die beiden Festlegungen zusammen: **Ohne Verschlüsselung gibt es keine verlässliche > Löschung.** Wer B will, muss A haben. Drei Stufen, weil drei verschiedene Absichten dahinterstehen: | Stufe | Was geschieht | Wofür | |---|---|---| | **Einstellungen zurücksetzen** | Netz, Kennwörter, Zertifikate, Einrichtungszustand. Der Bestand bleibt | Ausgesperrt, falsch eingerichtet | | **Sichere Datenlöschung** | Der Schlüssel wird vernichtet. Der Bestand ist damit unwiederbringlich | Weitergabe, Rückgabe, Vertragsende | | **Datenträger bereinigen** | Zusätzlich der Löschbefehl des Laufwerks selbst | Entsorgung, Reparatur außer Haus | Die zweite und dritte Stufe erzeugen einen **Löschnachweis** auf USB: Gerätekennung, Seriennummer des Laufwerks, angewandtes Verfahren, Zeitpunkt, Ergebnis. Das ist kein Beiwerk — bei einem Produkt, dessen Verkaufsargument der Nachweis ist, wäre eine Löschung ohne Beleg ein Widerspruch in sich. Und es ist genau das, was ein Kunde am Vertragsende verlangt. ## Der Schlüssel muss ohne Menschen verfügbar sein — und das ist die harte Stelle Ein Gerät im Serverraum muss nach einem Stromausfall von allein hochkommen. Niemand tippt um drei Uhr nachts eine Passphrase. Der Schlüssel bindet deshalb an den **Sicherheitsbaustein der Hardware**, der ihn nur herausgibt, wenn die Messung des Startzustands stimmt. **Damit wird aus einer Tresorfrage eine Gerätefrage.** Die offene Frage O-8 betraf bisher die Zugangsdaten; sie betrifft jetzt den gesamten Datenbestand. > **Und sie kollidiert mit dem Fassungswechsel.** Die Messung des Startzustands ändert sich mit > Kern und Startlader — also bei **jedem** Update. Wird der Schlüssel nicht vorher auch für die neue > Fassung hinterlegt, steht nach dem Umschalten ein Gerät da, das oben ist und an seine eigenen > Daten nicht herankommt. > > Das ist der schlimmste denkbare Ausgang: **nicht ein misslungenes Update, sondern ein > unerreichbarer Bestand.** Und der Rücksprung rettet es nur, solange die alte Messung noch gültig > ist. Daraus folgt eine Reihenfolge, die nicht verhandelbar ist: **Der Fassungswechsel hinterlegt den Schlüssel für die neue Fassung, solange die alte noch läuft und der Bereich offen ist — und erst danach schaltet er um.** Wird das vergessen, ist das kein Schönheitsfehler, sondern ein Datenverlust. ## Was daraus für den Nachweis folgt Zum ersten Nachweis des Erzeugnisses — der Rücksprung greift von selbst — kommt ein zweiter, und er ist genauso wichtig: > **Nach einem Fassungswechsel und nach einem Rücksprung ist der Bestandsbereich erreichbar.** Er lässt sich nur auf echter Hardware mit echtem Sicherheitsbaustein erbringen, nicht in einer virtuellen Maschine. ## Die Sicherung wird mit einem anderen Schlüssel verschlüsselt *Ergänzt am 20.08.2026 auf Entscheidung des CIO.* Eine Sicherung, die unverschlüsselt auf einem Netzlaufwerk des Kunden liegt, hebt die Verschlüsselung des Geräts vollständig auf. Sie wird deshalb ebenfalls verschlüsselt. **Dabei ist die Wahl des Schlüssels wichtiger als die Entscheidung selbst.** Eine Sicherung existiert für den Fall, dass das Gerät nicht mehr da ist. Würde sie mit dem Geräteschlüssel verschlüsselt — dem, der am Sicherheitsbaustein hängt —, wäre sie **genau dann unlesbar, wenn man sie braucht**: Gerät zerstört, Baustein weg, Schlüssel weg, Sicherung wertlos. Das wäre keine Sicherung, sondern eine aufwendige Art, Speicherplatz zu belegen. > **Die Sicherung trägt einen eigenen Schlüssel, der nicht am Gerät hängt und den der Kunde > verwahrt.** Er wird bei der Einrichtung erzeugt und einmalig ausgegeben. Daraus folgt eine Pflicht, die ins Handbuch und in die Einrichtung gehört: **Wer den Sicherungsschlüssel verliert, hat keine Sicherung.** Das muss bei der Ausgabe unmissverständlich dastehen — und die Ausgabe gehört in die Prüfspur, damit später nachweisbar ist, dass sie stattgefunden hat. ## Zum Sicherheitstoken als Schlüsselträger *Geprüft am 20.08.2026 auf Anregung des CIO.* Ein Hardware-Token kann an drei verschiedenen Stellen eingesetzt werden, und sie lösen **nicht dasselbe Problem**. Sie werden leicht verwechselt. | Einsatz | Was es leistet | Bewertung | |---|---|---| | **Als Wiederherstellung** — Token im Tresor des Kunden, entsperrt bei Ausfall des Sicherheitsbausteins | Löst den Totalverlust bei Defekt der Hauptplatine | **tragfähig** — aber eine ausgedruckte Wiederherstellungslosung leistet dasselbe ohne Lieferkette | | **Als Startbedingung** — Token steckt dauerhaft im Gerät | Das Laufwerk allein ist wertlos | **kein Gewinn gegenüber dem Sicherheitsbaustein**, siehe unten | | **Als zweiter Faktor** für die Verwaltung | Anmeldung an Konsole und Oberfläche | **eigenständig sinnvoll**, unabhängig von der Verschlüsselung | **Warum ein dauerhaft steckender Token nichts hinzufügt:** Er schützt gegen ein entwendetes Laufwerk — aber das tut der Sicherheitsbaustein auch, denn der ist auf der Hauptplatine verlötet. Gegen ein entwendetes **Gerät** schützt keiner von beiden, weil beide mitgehen. Der Token bringt also dieselbe Wirkung und zusätzlich ein Teil, das verloren gehen, herausgezogen oder vergessen werden kann. **Ein Fall ist trotzdem echt und verkaufbar:** Wenn der Token **bewusst entfernt** wird — beim Verlassen des Geländes, über Nacht, bei Außerbetriebnahme —, ist das Gerät ohne ihn nicht startfähig. Das ist eine Eigenschaft, die in Hochsicherheitsumgebungen verlangt wird, und sie hebt den Schutz über das hinaus, was ein verlöteter Baustein leisten kann. > **Festlegung: Der Sicherheitsbaustein bleibt der Regelweg. Ein Token ist eine Zusatzausstattung > für Kunden, die „startet nicht ohne Token" ausdrücklich verlangen — und dann mit der > ausgesprochenen Folge, dass das Gerät nach einem Stromausfall nicht von allein hochkommt.** Dieser letzte Halbsatz ist der Preis und gehört ins Datenblatt: Ein Gerät, das ohne Token nicht startet, kann nach einem nächtlichen Stromausfall nicht selbsttätig wiederkommen — es sei denn, der Token steckt, und dann ist man wieder beim Regelfall. **Was gegen Token in der Fläche spricht,** unabhängig von der Sicherheit: Je Gerät ein Stück Bestandsführung, Ersatzteile, ein weiterer Einzellieferant — und die Firmware eines Tokens lässt sich nicht aktualisieren, eine Schwachstelle wäre also ein Austausch über den ganzen Bestand hinweg. Bei einem Erzeugnis mit fünf Jahren Versorgungspflicht ist das ein Posten, der bedacht sein will. ## Die verworfenen Alternativen **Verschlüsselung als Option anbieten.** Verlockend, weil es die Entsperrung beim Start zunächst umgeht und die Ersteinrichtung vereinfacht. Dagegen steht, dass eine Sicherheitseigenschaft, die abschaltbar ist, im Zweifel abgeschaltet ist — und dass ein Gerät ohne sie keine verlässliche Löschung kennt. Ein Produkt, das in Banken und Verteidigungsbereiche verkauft werden soll, kann das nicht als Wahlmöglichkeit führen. **Löschen durch Überschreiben.** Der vertraute Weg, und auf drehenden Platten war er richtig. Auf Flash-Speichern ist er langsam und gibt eine Sicherheit vor, die er nicht hat. **Auch die Wurzeln verschlüsseln.** Kostet Vertraulichkeit, die es dort nicht zu schützen gibt, und verlegt die Entsperrung in den Startvorgang **vor** den Selbstprüflauf — womit ein Fehler dort das Gerät unrettbar macht, statt einen Rücksprung auszulösen. Der Rückweg ist mehr wert als die Verschlüsselung von Dateien, die auf jedem Gerät gleich sind. --- ## Nachtrag 02.09.2026 — kein Auslagerungsspeicher, und das ist eine Anforderung Beim Bau des Tresors als Pod ist eine Bedingung sichtbar geworden, die diese Entscheidung bisher nicht kannte und die genau ihr Schutzziel betrifft. **Der Tresor läuft mit abgeschaltetem Speicherfestnageln** (`disable_mlock`). In einem Behälter ist das praktisch unvermeidlich — das Festnageln verlangt ein Recht, das ein Pod im Regelfall nicht bekommt — und mit dem eingebauten Speicher auch vertretbar. **Es hat aber eine Bedingung:** > Ohne Festnageln darf der Arbeitsspeicher des Tresors **auf die Platte ausgelagert** werden. Das > ist genau der Speicher, in dem die **entschlüsselten** Zugangsdaten aller Zielsysteme des Kunden > stehen. **Damit entstünde eine zweite, unbewachte Kopie der Geheimnisse** — außerhalb des Tresors, außerhalb seiner Richtlinien, außerhalb der Prüfspur. Sie überlebt das Herunterfahren, und ihre Vernichtung wäre von keiner der Regeln oben erfasst. ### Die Festlegung > **Ein Xinion-Gerät hat keinen Auslagerungsspeicher. Das Abbild legt keinen an, und die > Installation bietet ihn nicht an.** Das ist keine Empfehlung und kein Feinschliff, sondern die Bedingung, unter der der abgeschaltete Speicherfestnagel überhaupt vertretbar ist. ### Warum es hierher gehört und nicht in die Nutzlast **Die Nutzlast kann es nicht durchsetzen.** Ein Pod bestimmt nicht, ob sein Wirt auslagert — das entscheidet die Geräteschicht, und zwar beim Bau des Abbilds. **Eine Anforderung, die nur die Nutzlast kennt, aber nur der Wirt erfüllen kann, ist genau die Art Lücke, die niemandem auffällt.** ### Was es kostet, und warum der Preis gering ist **Ohne Auslagerung ist ein Speicherüberlauf ein harter Abbruch** statt einer Verlangsamung. Das klingt schlechter, als es ist: Ein Gerät, das wegen Auslagerung zäh wird, sieht wie ein Leistungsproblem aus und wird tagelang gesucht. **Ein abgebrochener Pod startet neu und steht im Protokoll.** Die Auslegung nach Baugrößen macht die Rechnung ohnehin nicht auf Auslagerung auf — die Speicherbudgets der Pods kommen aus der Konfiguration und sind zuzuteilen, nicht zu verdrängen. ### Zwei Punkte, die daran hängen **Der Ruhezustand des Systems** (Suspend-to-Disk) schreibt denselben Speicher auf dieselbe Platte und ist damit aus demselben Grund ausgeschlossen. Er ist auf einem Rack-Gerät ohnehin sinnlos. **Ein Absturzabbild des Kerns** enthält ebenfalls Arbeitsspeicher. Ob und wohin eines geschrieben wird, ist **offen** und gehört mit derselben Überlegung entschieden — es berührt zugleich den Inhalt des Diagnosepakets aus `ADR-0007`. --- *Nachgetragen 02.09.2026 · Anlass: `disable_mlock` im Tresor-Pod, aufgefallen bei der Durchsicht der Aufbauten in `XinionONE/infra` · **Die Wirkung ist nicht gemessen** — dass ein Gerät ohne Auslagerungsspeicher unter Last sauber abbricht statt zu verklemmen, gehört auf dem Prüfgerät gezeigt.*