Kopīgs CA, atsevišķas duris: viens pakalpojums vienai uzņemšanas datnei

Sertifikāts, kas tiek validēts pret kopīgu iestādi, ir izturējis uzticības pārbaudi, nevis dalības pārbaudi. Šie divi lēmumi bieži tiek sajaukti, jo abi notiek savienošanās brīdī, un sajaukums paliek neredzams, līdz pakalpojumā tiek ielaists kāds, kam tur nevajadzētu būt. Risinājums nav otra iestāde; tas ir otrs lēmums, pieņemts katram pakalpojumam un pierakstīts tur, kur dēmons to lasa. Turiet abus atsevišķi, un lielākā daļa šīs jomas neskaidrību pazūd.

Uzticama ķēde neko nepasaka par dalību pakalpojumā

Divi pakalpojumi var pieņemt vienu un to pašu izdevējhierarhiju un tomēr būt ar atšķirīgām populācijām. Viens portatīvais dators pieder pirmajam un nedrīkst sasniegt otro, kamēr citi tās pašas hierarhijas klienti tiešām pieder tur. Iestādes noņemšana no šī pakalpojuma bloķētu visus, kas to lieto likumīgi, tāpēc darbs ir uzņemšana, nevis uzticība.

Palīdz iedomāties divas slēdzenes vienās durvīs. Sertifikāts atver ārējo slēdzeni, un lēmums par pakalpojumu atver iekšējo; neviens neaizstāj otru. Pakalpojums, kam ir tikai ārējā slēdze, dalību vispār neīsteno, tas tikai autentificē. Pierakstiet abus lēmumus pirms kaut ko mainīt, jo politiku, kas pastāv tikai strādājoša savienojuma formā, nevar auditēt. Tālāk runa ir par iekšējo slēdzeni.

Pārvērsiet neobligātos pārrakstus uzņemšanas vārtos

Klienta konfigurācijas direktorija parasti ir ērtība: datnes tajā pārraksta to klientu iestatījumus, kurus tās nosauc, un klients bez datnes vienkārši darbojas ar servera noklusējuma vērtībām. Viena direktīva pārvērš šo ērtību vārtos, tā ka trūkstoša datne nozīmē, ka savienojums tiek noraidīts.

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

Kopienas izdevums OpenVPN 2.6 ccd-exclusive savā rokasgrāmatas lapā dokumentē tieši šo nosacījumu, un nosauktās datnes meklēšana ir atkarīga no klienta faktiskās identitātes. Citas būves un produktu pārvaldīti serveri var atšķirties, tāpēc pirms paļauties uz to pašu semantiku citur, apstipriniet instalēto versiju.

Uzskatiet iepriekš minēto ceļu par piemēru un pārbaudiet faktiski izvietoto izkārtojumu, nevis veidojiet direktoriju, ko izdomājusi kāda rokasgrāmata. Atstājiet esošās sertifikātu pārbaudes, servera identitātes pārbaudes un konta autentifikāciju tieši tādas, kādas tās bija, jo fragments pievieno nosacījumu un neko neizņem. Sagatavojiet izmaiņas pirms ražošanas, jo nepareizā vietā izraisīts noraidījums izskatās kā sertifikāta kļūme un novirza izmeklēšanu uz iestādi. Pēc tam apstipriniet, ka noraidītā klienta žurnāla rinda nosauc trūkstošo konfigurācijas datni, nevis ķēdi.

Viena direktorija katram pakalpojumam, nevis viens kopīgs saraksts

Dalība pieder pakalpojumam, kas to īsteno, tāpēc katrs pakalpojums tur savu direktoriju un savas datnes. Divu pakalpojumu norādīšana uz vienu sarakstu liek tiem dalīties dalībā vai kāds to gribēja vai nē, un radušās izmaiņas ir grūti izsekot līdz lēmumam. Kopīgā iestāde var palikt kopīga; uzņemšanas datnes nevar. To atdalīšana nozīmē arī to, ka kļūda vienā pakalpojumā nevar klusi paplašināt citu.

DEFAULT ieraksts ir gadījums, kas maldina cilvēkus. Tas nodrošina rezerves iestatījumus, kad nosauktā datne netiek atrasta, bet tas nav nosauktā datne, ko pieprasa vārti, tāpēc tas nevar uzņemt klientu viens pats. Pārbaudiet klientu, kam vispār nav ieraksta, un apstipriniet noraidījumu; ja šis klients tiek uzņemts, rezerve tiek piemērota un ccd-exclusive šajā instancē nav spēkā.

Faktiskā identitāte izlemj, kura datne tiek lasīta

Meklēšana izmanto identitāti, ar kuru klients faktiski autentificējās, kas parasti ir sertifikāta vispārpieņemtais nosaukums. Ja serveris pārbauda arī lietotājvārdu un paroli un kartē šo nosaukumu uz vispārpieņemto nosaukumu, datnei tā vietā jāatbilst autentificētajam lietotājvārdam. Neatbilstība atstāj direktoriju pilnu ticamu datņu nosaukumu, kas nekad netiek izvēlēti.

Lasīšana ir otrā puse. Dēmons parasti atsakās no privilēģijām pēc palaišanas, tāpēc samazinātajam kontam ir nepieciešama lasīšanas piekļuve direktorijai un katram ierakstam tajā. Klientiem nevajadzētu varēt izveidot savu ierakstu pa jebkuru rakstāmu ceļu, jo pašapkalpošanās uzņemšana pilnībā iznīcina mehānismu. Pārbaudiet montēšanas un koplietošanas atļaujas, ne tikai datnes režīmu, jo direktorija, kas izskatās slēgta vienam kontam, var būt atvērta citam. Pēc tam apstipriniet, kuru kontu darbīgais process patiešām izmanto, nevis kuru kontu piemin unit datne. Abi ir vienādi tikai tad, kad nekas cits tos nav mainījis.

Novērojiet noraidījumu, uzņemšanu un atsaukšanu atsevišķi

Izmēģiniet identitāti, kas pieder pakalpojumam, un apstipriniet, ka tā savienojas. Izmēģiniet derīgu sertifikātu bez ieraksta un apstipriniet, ka tas tiek noraidīts. Izmēģiniet identitāti, kas uzņemta citā pakalpojumā, un apstipriniet, ka tā šeit netiek uzņemta. Pierakstiet pakalpojuma instanci un faktisko identitāti blakus katram rezultātam, jo rezultātu bez šī konteksta neviens cits nevar atkārtot.

Atsaukšana ir atsevišķa darbība no anulēšanas. Uzņemšanas datnes rediģēšana noņem tiesības uz vienu pakalpojumu, kamēr identitāte paliek derīga visur citur, savukārt kompromitēta atslēga prasa organizācijas anulēšanas atbildi. Iepriekš izlemiet, kas notiks ar jau izveidotajām sesijām, jo ne direktorijas rediģēšana, ne anulēšanas saraksts tās pašas par sevi nebeidz.

Uzņemšana arī ir tikai pirmie vārti. Pievienošanās pakalpojumam neko nepasaka par apakštīkliem, datubāzēm vai pārvaldības saskarnēm aiz tā, un šī resursu politika ir jāraksta un jāpārbauda atsevišķi.