Sichere Standardeinstellungen und Fail-Closed-Design

Worum es geht

Das Papier von Saltzer und Schroeder aus dem Jahr 1975 listet acht Designprinzipien für Schutzmechanismen auf. Das zweite, Fail-Safe Defaults, verlangt, Zugriffsentscheidungen auf Erlaubnis statt auf Ausschluss zu stützen: Der Standardzustand ist fehlender Zugriff, und der Mechanismus legt die Bedingungen fest, unter denen Zugriff erlaubt ist. Ihre Begründung betrifft die Fehlerarten: Ein Fehler in einem Mechanismus, der ausdrückliche Erlaubnis gewährt, schlägt tendenziell so fehl, dass die Erlaubnis verweigert wird, was rasch auffällt, während ein Fehler in einem Mechanismus, der auflistet, was auszuschliessen ist, tendenziell so fehlschlägt, dass Zugriff erlaubt wird, was im normalen Betrieb unbemerkt bleiben kann. Das OWASP-Merkblatt zum sicheren Produktdesign formuliert das um in «sichere Standardeinstellungen festlegen, die Angriffsfläche minimieren und bei diesen klar definierten und verstandenen Standardeinstellungen sicher ausfallen», und fordert unter seinen Konfigurationsempfehlungen Systeme, die standardmässig sicher sind und bei einer Fehlfunktion sicher ausfallen, statt Schwachstellen offenzulegen.

Warum es wichtig ist

Viele konfigurationsbedingte Schwachstellen sind banal: ein aktiviert gelassener Debug-Endpunkt, ein standardmässig öffentlicher Speicher, eine Autorisierungsprüfung, die eine fehlende Rolle als «keine Einschränkungen» behandelte, eine Strategieabfrage, die in ein Timeout lief und übersprungen wurde. Jedes davon ist ein Design, das offen ausfällt (fail open). Ein Fail-Closed-Design macht aus denselben Fehlern sichtbare Fehler: einen 403, einen verweigerten Start, einen fehlschlagenden Test.

So wird es angewendet

• Autorisierung: von Verweigerung ausgehen und aufzählen, was erlaubt ist (Rollen, Routen, Ursprünge, Hosts); die Strategie nie als Liste verbotener Dinge formulieren.
• Konfiguration: sicherheitsrelevante Einstellungen (Signaturschlüssel, erlaubte Hosts, TLS-Modus) ausdrücklich verlangen und den Start verweigern, wenn sie fehlen oder fehlerhaft sind, statt einen freizügigen Wert einzusetzen. Wo ein Standardwert bestehen muss, den produktionssicheren ausliefern.
• Fehlerpfade: Ist eine Abhängigkeit, auf die sich die Prüfung stützt (Session-Speicher, Strategiedienst, Schlüsselspeicher), nicht verfügbar, verweigern und alarmieren; «konnte nicht geprüft werden» ist nicht «geprüft».
• Debug-Schalter und Feature-Flags standardmässig aus, und entfernt statt belassen.
• Eingaben: akzeptieren, was ausdrücklich erlaubt ist (Schemas, Aufzählungen), statt bekannte schlechte Muster herauszufiltern.
• Überprüfung: bei jeder neuen Prüfung fragen, was bei Ausnahme, Timeout, Null und leerer Liste geschieht.

Stolpersteine

Fail-Closed ist der richtige Standard für Zugriffskontrolle, nicht für jede Funktion: ein Health-Check, der fail-closed ausfällt, kann einen Dienst lahmlegen, und ein Betrugsfilter, der bei einem Ausfall blockiert, stoppt sämtliche Zahlungen. Je Mechanismus entscheiden, welche Richtung sicher ist, und das festhalten. Sichere Standardeinstellungen, die den ersten Lauf mühsam machen, werden durch kopierte «Sicherheit deaktivieren»-Schnipsel ausser Kraft gesetzt; sie mit Fehlermeldungen kombinieren, die genau sagen, was einzustellen ist.