Delad CA, separata dörrar: en tjänst per tillträdesfil

Ett certifikat som valideras mot en delad auktoritet har klarat ett test av förtroende, inte ett test av medlemskap. De två besluten slås ofta ihop eftersom båda sker vid anslutningen, och sammanslagningen förblir osynlig tills någon som inte borde vara på en tjänst släpps in där. Lösningen är inte en andra auktoritet; det är ett andra beslut, fattat per tjänst och nedtecknat där daemonen läser det. Håll de två åtskilda och det mesta av förvirringen på området försvinner.

En betrodd kedja säger ingenting om tjänstemedlemskap

Två tjänster kan acceptera samma utfärdande hierarki och ändå ha olika populationer. En bärbar dator hör till den första och får inte nå den andra, medan andra klienter från samma hierarki faktiskt hör dit. Att ta bort auktoriteten från den tjänsten skulle låsa ute alla som använder den lagligt, så arbetet är tillträde, inte förtroende.

Det hjälper att föreställa sig två lås på en dörr. Certifikatet öppnar det yttre låset, och ett beslut per tjänst öppnar det inre; inget av dem ersätter det andra. En tjänst med bara det yttre låset upprätthåller inte medlemskap alls, den autentiserar bara. Skriv ned båda besluten innan du ändrar något, för en policy som bara finns i form av en fungerande anslutning kan inte granskas. Det som följer handlar om det inre låset.

Gör valfria överstyrningar till en tillträdesport

En klientkonfigurationskatalog är normalt en bekvämlighet: filer i den åsidosätter inställningar för de klienter de namnger, och en klient utan fil körs helt enkelt med serverns standardvärden. Ett direktiv förvandlar den bekvämligheten till en port, så att en saknad fil innebär att anslutningen avvisas.

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

Communityutgåvan av OpenVPN 2.6 ccd-exclusive dokumenterar på sin manualsida just detta villkor, och sökningen efter den namngivna filen beror på klientens effektiva identitet. Andra byggen och produktstyrda servrar kan skilja sig, så bekräfta den installerade versionen innan du förlitar dig på samma semantik någon annanstans.

Betrakta sökvägen ovan som ett exempel och kontrollera den faktiskt utrullade layouten i stället för att skapa en katalog som en guide har hittat på. Låt de befintliga certifikatkontrollerna, serveridentitetskontrollerna och kontogodkännandet vara exakt som de var, eftersom fragmentet lägger till ett villkor och tar bort ingenting. Förbered ändringen före produktion, eftersom en avvisning som reses på fel ställe ser ut som ett certifikatfel och skickar utredningen mot auktoriteten. Bekräfta därefter att loggrader för en avvisad klient namnger den saknade konfigurationsfilen och inte kedjan.

En katalog per tjänst, inte en delad lista

Medlemskap tillhör den tjänst som upprätthåller det, så varje tjänst håller sin egen katalog och sina egna filer. Att peka två tjänster mot en lista får dem att dela medlemskap oavsett om någon avsåg det eller inte, och den resulterande ändringen är svår att spåra tillbaka till ett beslut. Den delade auktoriteten kan förbli delad; tillträdesfilerna kan inte. Att hålla dem åtskilda innebär också att ett fel i en tjänst inte tyst kan utöka en annan.

En DEFAULT-post är fallet som vilseleder människor. Den tillhandahåller reservinställningar när ingen namngiven fil hittas, men det är inte den namngivna fil som porten kräver, så den kan inte släppa in en klient på egen hand. Testa en klient som inte har någon post alls och bekräfta avvisningen; om den klienten släpps in tillämpas reserven och ccd-exclusive är inte i kraft i den instansen.

Den effektiva identiteten avgör vilken fil som läses

Sökningen använder den identitet som klienten faktiskt autentiserade som, vilket normalt är certifikatets common name. Där servern också verifierar ett användarnamn och lösenord och mappar det namnet till common name måste filen i stället matcha det autentiserade användarnamnet. En avvikelse lämnar en katalog full av trovärdiga filnamn som aldrig väljs.

Läsningen är den andra halvan. Daemonen släpper vanligtvis privilegier efter start, så det reducerade kontot behöver läsåtkomst till katalogen och varje post i den. Klienter får inte kunna skapa sin egen post via någon skrivbar sökväg, eftersom självbetjäningstillträde helt undergräver mekanismen. Kontrollera monterings- och delningsbehörigheterna och inte bara filläget, eftersom en katalog som ser stängd ut för ett konto kan vara öppen för ett annat. Bekräfta sedan vilket konto den körande processen verkligen använder, i stället för vilket konto unit-filen nämner. De två är bara lika när ingenting annat har ändrat dem.

Observera avvisning, tillträde och återkallelse var för sig

Prova en identitet som hör till tjänsten och bekräfta att den ansluter. Prova ett giltigt certifikat utan post och bekräfta att det avvisas. Prova en identitet som släppts in på den andra tjänsten och bekräfta att den inte släpps in här. Notera tjänstinstansen och den effektiva identiteten bredvid varje resultat, för ett resultat utan den kontexten kan ingen annan återskapa.

Återtagandet är en annan operation än återkallelsen. Redigering av en tillträdesfil tar bort en tjänstebehörighet medan identiteten förblir giltig överallt annars, medan en komprometterad nyckel kräver organisationens återkallelserespons. Bestäm i förväg vad som händer med sessioner som redan är uppe, eftersom varken en katalogredigering eller en återkallelselista avslutar dem av sig själva.

Tillträde är också bara den första porten. Att gå med i en tjänst säger ingenting om subnäten, databaserna eller administrationsgränssnitten bakom den, och den ressurspolicyn måste skrivas och testas för sig.