CA e përbashkët, dyer të ndara: një shërbim për çdo skedar pranimi

Një certifikatë që vërtetohet kundrejt një autoriteti të përbashkët ka kaluar një provë besimi, jo një provë anëtarësie. Këto dy vendime shpesh ngatërrohen sepse të dyja ndodhin në momentin e lidhjes, dhe ngatërrimi mbetet i padukshëm derisa dikush që nuk duhet të jetë në një shërbim pranohet atje. Zgjidhja nuk është një autoritet i dytë; është një vendim i dytë, i marrë për çdo shërbim dhe i regjistruar atje ku daemoni e lexon. Mbani të dyja të ndara dhe pjesa më e madhe e konfuzionit në këtë fushë zhduket.

Një zinxhir i besuar nuk thotë asgjë për anëtarësinë në shërbim

Dy shërbime mund të pranojnë të njëjtën hierarki lëshuesi dhe gjithsesi të kenë popullata të ndryshme. Një laptop i përket të parit dhe nuk duhet të arrijë të dytin, ndërsa klientë të tjerë të së njëjtës hierarki i përkasin vërtet atje. Heqja e autoritetit nga ai shërbim do të bllokonte të gjithë ata që e përdorin ligjërisht, kështu që puna është pranim, jo besim.

Ndihmon të imagjinohen dy bravë në një derë. Certifikata hap bravën e jashtme, dhe një vendim për çdo shërbim hap të brendshmen; asnjëra nuk zëvendëson tjetrën. Një shërbim vetëm me bravën e jashtme nuk zbaton fare anëtarësi, ai vetëm vërteton identitetin. Shkruani të dyja vendimet para se të ndryshoni diçka, sepse një politikë që ekziston vetëm në formën e një lidhjeje funksionale nuk mund të auditohet. Ajo që vijon ka të bëjë me bravën e brendshme.

Ktheni mbivendosjet opsionale në një portë pranimi

Një drejtori konfigurimi e klientit është zakonisht një lehtësi: skedarët në të mbivendosin cilësimet e klientëve që emërtojnë, dhe një klient pa skedar thjesht funksionon me vlerat e paracaktuara të serverit. Një direktivë e kthen atë lehtësi në një portë, kështu që një skedar që mungon do të thotë që lidhja refuzohet.

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

Botimi i komunitetit i OpenVPN 2.6 ccd-exclusive dokumenton në faqen e manualit të tij pikërisht këtë kusht, dhe kërkimi i skedarit të emërtuar varet nga identiteti efektiv i klientit. Ndërtime të tjera dhe serverë të menaxhuar nga produkte mund të ndryshojnë, prandaj konfirmoni versionin e instaluar përpara se të mbështeteni në të njëjtën semantikë diku tjetër.

Trajtoni shtegun më sipër si shembull dhe kontrolloni paraqitjen e vendosur në të vërtetë në vend që të krijoni një drejtori të sajuar nga një udhëzues. Lërini kontrollet e certifikatave, kontrollet e identitetit të serverit dhe vërtetimin e llogarisë saktësisht siç ishin, sepse fragmenti shton një kusht dhe nuk heq asgjë. Përgatitni ndryshimin para prodhimit, pasi një refuzim i ngritur në vendin e gabuar duket si dështim certifikate dhe e drejton hetimin te autoriteti. Më pas konfirmoni që rreshti i regjistrit për një klient të refuzuar përmend skedarin e konfigurimit që mungon dhe jo zinxhirin.

Një drejtori për çdo shërbim, jo një listë e përbashkët

Anëtarësia i përket shërbimit që e zbaton, kështu që çdo shërbim mban drejtorinë e vet dhe skedarët e vet. Drejtimi i dy shërbimeve nga një listë i bën ata të ndajnë anëtarësinë pavarësisht nëse dikush e kishte për qëllim apo jo, dhe ndryshimi që rezulton është i vështirë të gjurmohet deri në një vendim. Autoriteti i përbashkët mund të mbetet i përbashkët; skedarët e pranimit nuk mund të mbeten. Mbajtja e tyre të ndara do të thotë gjithashtu se një gabim në një shërbim nuk mund të zgjerojë në heshtje një tjetër.

Një zë DEFAULT është rasti që i mashtron njerëzit. Ai ofron cilësime rezervë kur nuk gjendet asnjë skedar i emërtuar, por nuk është skedari i emërtuar që kërkon porta, ndaj nuk mund të pranojë një klient vetë. Testoni një klient që nuk ka fare zë dhe konfirmoni refuzimin; nëse ai klient pranohet, po zbatohet rezerva dhe ccd-exclusive nuk është në fuqi në atë instancë.

Identiteti efektiv vendos cili skedar lexohet

Kërkimi përdor identitetin me të cilin klienti u vërtetua vërtet, që zakonisht është emri i përbashkët i certifikatës. Kur serveri verifikon gjithashtu një emër përdoruesi dhe fjalëkalim dhe e pasqyron atë emër në emrin e përbashkët, skedari duhet të përputhet me emrin e përdoruesit të vërtetuar. Mospërputhja lë një drejtori plot me emra skedarësh të besueshëm që nuk zgjidhen kurrë.

Leximi është gjysma tjetër. Daemoni zakonisht heq dorë nga privilegjet pas nisjes, kështu që llogaria e reduktuar ka nevojë për akses leximi në drejtori dhe në çdo zë brenda saj. Klientët nuk duhet të mund të krijojnë zërin e tyre përmes asnjë shtegu të shkruajtshëm, sepse pranimi vetë-shërbim e zhvleftëson plotësisht mekanizmin. Kontrolloni lejet e montimit dhe të ndarjes dhe jo vetëm mënyrën e skedarit, pasi një drejtori që duket e mbyllur për një llogari mund të jetë e hapur për një tjetër. Më pas konfirmoni cilën llogari procesi në punë përdor vërtet, dhe jo cilën llogari përmend skedari unit. Të dyja janë njësoj vetëm kur asgjë tjetër nuk i ka ndryshuar.

Vëzhgoni refuzimin, pranimin dhe revokimin veçmas

Provoni një identitet që i përket shërbimit dhe konfirmoni se lidhet. Provoni një certifikatë të vlefshme pa zë dhe konfirmoni se refuzohet. Provoni një identitet të pranuar në shërbimin tjetër dhe konfirmoni se nuk pranohet këtu. Shënoni instancën e shërbimit dhe identitetin efektiv pranë çdo rezultati, sepse një rezultat pa atë kontekst askush tjetër nuk mund ta riprodhojë.

Tërheqja është një veprim i veçantë nga revokimi. Redaktimi i një skedari pranimi heq një të drejtë për një shërbim, ndërsa identiteti mbetet i vlefshëm kudo tjetër, kurse një çelës i komprometuar kërkon përgjigjen e revokimit të organizatës. Vendosni paraprakisht çfarë ndodh me sesionet tashmë të vendosura, pasi as redaktimi i drejtorisë as lista e revokimit nuk i mbyll ato vetë.

Pranimi është gjithashtu vetëm porta e parë. Bashkimi me një shërbim nuk thotë asgjë për nënrrjetet, bazat e të dhënave ose ndërfaqet e menaxhimit pas tij, dhe ajo politikë e burimeve duhet të shkruhet dhe të testohet veçmas.