Gemeinsame CA, getrennte Türen: ein Dienst pro Zulassungsdatei

Ein Zertifikat, das gegen eine gemeinsame Autorität validiert, hat einen Vertrauenstest bestanden, keinen Mitgliedschaftstest. Beide Entscheidungen werden oft vermischt, weil sie beide beim Verbindungsaufbau geschehen, und die Vermischung bleibt unsichtbar, bis jemand in einen Dienst gelassen wird, der dort nicht hingehört. Die Lösung ist keine zweite Autorität; sie ist eine zweite Entscheidung, pro Dienst getroffen und dort festgehalten, wo der Daemon sie liest. Halten Sie beides getrennt, und der größte Teil der Verwirrung in diesem Bereich verschwindet.

Eine vertrauenswürdige Kette sagt nichts über Dienstmitgliedschaft

Zwei Dienste können dieselbe ausstellende Hierarchie akzeptieren und dennoch unterschiedliche Populationen haben. Ein Laptop gehört zum ersten und darf den zweiten nicht erreichen, während andere Clients derselben Hierarchie dort tatsächlich hingehören. Die Autorität aus diesem Dienst zu entfernen, würde alle aussperren, die ihn rechtmäßig nutzen, also ist die Arbeit Zulassung und nicht Vertrauen.

Es hilft, sich zwei Schlösser an einer Tür vorzustellen. Das Zertifikat öffnet das äußere Schloss, und eine dienstbezogene Entscheidung öffnet das innere; keines ersetzt das andere. Ein Dienst mit nur dem äußeren Schloss erzwingt überhaupt keine Mitgliedschaft, er authentifiziert lediglich. Schreiben Sie beide Entscheidungen auf, bevor Sie etwas ändern, denn eine Richtlinie, die nur in Gestalt einer funktionierenden Verbindung existiert, lässt sich nicht prüfen. Das Folgende betrifft das innere Schloss.

Machen Sie optionale Überschreibungen zu einem Zulassungstor

Ein Client-Konfigurationsverzeichnis ist normalerweise eine Annehmlichkeit: Dateien darin überschreiben Einstellungen für die Clients, die sie benennen, und ein Client ohne Datei läuft einfach mit den Servervorgaben. Eine Direktive verwandelt diese Annehmlichkeit in ein Tor, sodass eine fehlende Datei bedeutet, dass die Verbindung abgelehnt wird.

client-config-dir /etc/openvpn/service-a/clients
ccd-exclusive

Die Community-Ausgabe von OpenVPN 2.6 ccd-exclusive in ihrer Handbuchseite dokumentiert genau diese Bedingung, und die Suche nach der benannten Datei richtet sich nach der effektiven Client-Identität. Andere Builds und produktverwaltete Server können abweichen, prüfen Sie daher die installierte Version, bevor Sie sich anderswo auf dieselbe Semantik verlassen.

Behandeln Sie den obigen Pfad als Beispiel und prüfen Sie das tatsächlich ausgerollte Layout, statt ein Verzeichnis anzulegen, das sich ein Leitfaden ausgedacht hat. Lassen Sie die bestehenden Zertifikatsprüfungen, Serveridentitätsprüfungen und Kontoauthentifizierung genau so, wie sie waren, denn das Fragment fügt eine Bedingung hinzu und entfernt nichts. Bereiten Sie die Änderung vor der Produktion vor, da eine Ablehnung am falschen Punkt wie ein Zertifikatsfehler aussieht und die Untersuchung zur Autorität schickt. Bestätigen Sie anschließend, dass die Protokollzeile für einen abgelehnten Client die fehlende Konfigurationsdatei nennt und nicht die Kette.

Ein Verzeichnis pro Dienst, nicht eine gemeinsame Liste

Mitgliedschaft gehört zu dem Dienst, der sie erzwingt, also hält jeder Dienst sein eigenes Verzeichnis und seine eigenen Dateien. Zwei Dienste auf eine Liste zu zeigen lässt sie Mitgliedschaft teilen ob jemand das beabsichtigte oder nicht, und die resultierende Änderung lässt sich schwer auf eine Entscheidung zurückführen. Die gemeinsame Autorität kann gemeinsam bleiben; die Zulassungsdateien nicht. Sie getrennt zu halten bedeutet auch, dass ein Fehler in einem Dienst einen anderen nicht stillschweigend erweitern kann.

Ein DEFAULT-Eintrag ist der Fall, der Menschen in die Irre führt. Er liefert Ausweicheinstellungen, wenn keine benannte Datei gefunden wird, aber er ist nicht die benannte Datei, die das Tor verlangt, also kann er einen Client nicht allein zulassen. Testen Sie einen Client ohne jeglichen Eintrag und bestätigen Sie die Ablehnung; wird dieser Client zugelassen, greift der Rückfall und ccd-exclusive ist in dieser Instanz nicht in Kraft.

Die effektive Identität entscheidet, welche Datei gelesen wird

Die Suche verwendet die Identität, als die sich der Client tatsächlich authentifiziert hat, normalerweise der Common Name des Zertifikats. Wo der Server außerdem Benutzername und Passwort prüft und diesen Namen auf den Common Name abbildet, muss die Datei stattdessen zum authentifizierten Benutzernamen passen. Eine Abweichung hinterlässt ein Verzeichnis voller plausibler Dateinamen, die nie ausgewählt werden.

Lesen ist die andere Hälfte. Der Daemon gibt nach dem Start üblicherweise Privilegien ab, also benötigt das reduzierte Konto Lesezugriff auf das Verzeichnis und jeden Eintrag darin. Clients dürfen ihren eigenen Eintrag nicht über irgendeinen beschreibbaren Pfad anlegen können, denn Selbstbedienungszulassung hebt den Mechanismus vollständig auf. Prüfen Sie die Mount- und Freigabeberechtigungen und nicht nur den Dateimodus, da ein Verzeichnis, das für ein Konto geschlossen aussieht, für ein anderes offen sein kann. Bestätigen Sie dann, welches Konto der laufende Prozess wirklich verwendet, statt welches Konto die Unit-Datei erwähnt. Beide sind nur dann gleich, wenn nichts anderes sie geändert hat.

Beobachten Sie Ablehnung, Zulassung und Widerruf getrennt

Versuchen Sie eine Identität, die zum Dienst gehört, und bestätigen Sie, dass sie sich verbindet. Versuchen Sie ein gültiges Zertifikat ohne Eintrag und bestätigen Sie, dass es abgelehnt wird. Versuchen Sie eine Identität, die zum anderen Dienst zugelassen ist, und bestätigen Sie, dass sie hier nicht zugelassen wird. Notieren Sie die Dienstinstanz und die effektive Identität neben jedem Ergebnis, denn ein Ergebnis ohne diesen Kontext kann niemand sonst reproduzieren.

Die Rücknahme ist ein anderer Vorgang als der Widerruf. Das Bearbeiten einer Zulassungsdatei entzieht eine Dienstberechtigung, während die Identität überall sonst gültig bleibt, wohingegen ein kompromittierter Schlüssel die Widerrufsreaktion der Organisation erfordert. Entscheiden Sie vorab, was mit bereits aufgebauten Sitzungen geschieht, da weder eine Verzeichnisbearbeitung noch eine Widerrufsliste sie von selbst beendet.

Zulassung ist auch nur das erste Tor. Einem Dienst beizutreten sagt nichts über die Subnetze, Datenbanken oder Verwaltungsschnittstellen dahinter, und diese Ressourcenrichtlinie muss für sich geschrieben und getestet werden.