Gedeelde CA, aparte deuren: één dienst per toegangsbestand

Een certificaat dat tegen een gedeelde autoriteit wordt gevalideerd, is geslaagd voor een vertrouwenstest, niet voor een lidmaatschapstest. Die twee beslissingen worden vaak samengevoegd omdat ze beide bij het verbinden gebeuren, en de samenvoeging blijft onzichtbaar tot iemand die er niet hoort op een dienst wordt toegelaten. De oplossing is geen tweede autoriteit; het is een tweede beslissing, per dienst genomen en vastgelegd waar de daemon die leest. Houd de twee gescheiden en het meeste misverstand op dit terrein verdwijnt.

Een vertrouwde keten zegt niets over dienstlidmaatschap

Twee diensten kunnen dezelfde uitgevende hiërarchie accepteren en toch verschillende populaties hebben. Eén laptop hoort bij de eerste en mag de tweede niet bereiken, terwijl andere clients van dezelfde hiërarchie daar wel bij horen. De autoriteit uit die dienst verwijderen zou iedereen buitensluiten die hem rechtmatig gebruikt, dus het werk is toelating en niet vertrouwen.

Het helpt om twee sloten op één deur te bedenken. Het certificaat opent het buitenste slot, en een beslissing per dienst opent het binnenste; geen van beide vervangt het andere. Een dienst met alleen het buitenste slot handhaaft helemaal geen lidmaatschap, hij authenticeert alleen. Schrijf beide beslissingen op voordat je iets wijzigt, want een beleid dat alleen bestaat in de vorm van een werkende verbinding kan niet worden geaudit. Wat volgt gaat over het binnenste slot.

Maak optionele overschrijvingen tot een toegangspoort

Een clientconfiguratiemap is meestal een gemak: bestanden erin overschrijven instellingen voor de clients die ze noemen, en een client zonder bestand draait gewoon met de standaardwaarden van de server. Eén richtlijn verandert dat gemak in een poort, zodat een ontbrekend bestand betekent dat de verbinding wordt geweigerd.

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

De community-editie van OpenVPN 2.6 ccd-exclusive documenteert op zijn handmatige pagina precies deze voorwaarde, en het opzoeken van het genoemde bestand hangt af van de effectieve clientidentiteit. Andere builds en door producten beheerde servers kunnen afwijken, dus controleer de geïnstalleerde versie voordat je elders op dezelfde semantiek vertrouwt.

Behandel het pad hierboven als een voorbeeld en controleer de daadwerkelijk uitgerolde indeling in plaats van een map te maken die een handleiding heeft bedacht. Laat de bestaande certificaatcontroles, serveridentiteitscontroles en accountauthenticatie precies zoals ze waren, want het fragment voegt een voorwaarde toe en verwijdert niets. Bereid de wijziging voor productie voor, omdat een weigering op het verkeerde punt op een certificaatfout lijkt en het onderzoek naar de autoriteit stuurt. Bevestig daarna dat de logregel voor een geweigerde client het ontbrekende configuratiebestand noemt en niet de keten.

Eén map per dienst, niet één gedeelde lijst

Lidmaatschap hoort bij de dienst die het handhaaft, dus elke dienst houdt zijn eigen map en zijn eigen bestanden. Twee diensten naar één lijst wijzen laat ze lidmaatschap delen of iemand dat nu bedoelde of niet, en de resulterende wijziging is moeilijk terug te voeren op een beslissing. De gedeelde autoriteit kan gedeeld blijven; de toegangsbestanden niet. Ze gescheiden houden betekent ook dat een fout in de ene dienst een andere niet stil kan verruimen.

Een DEFAULT-regel is het geval dat mensen misleidt. Hij levert reserve-instellingen wanneer geen genoemd bestand wordt gevonden, maar het is niet het genoemde bestand dat de poort vereist, dus hij kan een client niet op zichzelf toelaten. Test een client die helemaal geen regel heeft en bevestig de weigering; als die client wordt toegelaten, wordt de reserve toegepast en ccd-exclusive is in dat exemplaar niet van kracht.

De effectieve identiteit bepaalt welk bestand wordt gelezen

De opzoeking gebruikt de identiteit waarmee de client zich werkelijk heeft geauthenticeerd, meestal de common name van het certificaat. Waar de server ook een gebruikersnaam en wachtwoord verifieert en die naam op de common name afbeeldt, moet het bestand in plaats daarvan overeenkomen met de geauthenticeerde gebruikersnaam. Een mismatch laat een map vol aannemelijke bestandsnamen achter die nooit worden gekozen.

Lezen is de andere helft. De daemon geeft na het starten meestal privileges op, dus het verlaagde account heeft leestoegang nodig tot de map en elk item erin. Clients mogen hun eigen regel niet kunnen aanmaken via een beschrijfbaar pad, want zelfbedieningstoelating ondermijnt het mechanisme volledig. Controleer de mount- en deelrechten en niet alleen de bestandsmodus, omdat een map die voor het ene account gesloten lijkt voor het andere open kan zijn. Bevestig daarna welk account het draaiende proces werkelijk gebruikt, in plaats van welk account het unit-bestand noemt. Die twee zijn alleen gelijk als niets anders ze heeft gewijzigd.

Observeer weigering, toelating en intrekking afzonderlijk

Probeer een identiteit die bij de dienst hoort en bevestig dat die verbindt. Probeer een geldig certificaat zonder regel en bevestig dat het wordt geweigerd. Probeer een identiteit die bij de andere dienst is toegelaten en bevestig dat die hier niet wordt toegelaten. Noteer het dienstexemplaar en de effectieve identiteit naast elk resultaat, want een resultaat zonder die context kan niemand anders reproduceren.

Intrekking van toegang is een andere bewerking dan herroeping. Het bewerken van een toegangsbestand verwijdert één dienstrecht terwijl de identiteit overal elders geldig blijft, terwijl een gecompromitteerde sleutel de herroepingsreactie van de organisatie vereist. Beslis vooraf wat er gebeurt met sessies die al actief zijn, want noch een mapbewerking noch een herroepingslijst beëindigt ze vanzelf.

Toelating is ook slechts de eerste poort. Lid worden van een dienst zegt niets over de subnetten, databases of beheerinterfaces erachter, en dat resourcebeleid moet apart worden geschreven en getest.