Ortaq CA, ayrı qapılar: hər qəbul faylı üçün bir xidmət

Ortaq orqana qarşı doğrulanan sertifikat etibar yoxlamasından keçmişdir, üzvlük yoxlamasından deyil. Bu iki qərar tez-tez birləşdirilir, çünki ikisi də qoşulma anında baş verir və bu birləşmə xidmətdə olmamalı olan kimsə oraya qəbul edilənə qədər görünməz qalır. Düzəliş ikinci orqan deyil; xidmətə görə verilən və daemonun oxuduğu yerdə qeyd edilən ikinci qərardır. İkisini ayrı saxlayın və bu sahədəki qarışıqlığın çoxu yox olar.

Etibarlı zəncir xidmət üzvlüyü barədə heç nə demir

İki xidmət eyni verən iyerarxiyanı qəbul edə, lakin fərqli istifadəçi kütlələrinə malik ola bilər. Bir noutbuk birinciyə aiddir və ikinciyə çatmamalıdır, halbuki həmin iyerarxiyanın digər müştəriləri ora həqiqətən aiddir. Orqanı həmin xidmətdən çıxarmaq ondan qanuni istifadə edən hamını kənarda qoyardı, ona görə də iş etibar deyil, qəbuldur.

Bir qapıda iki kilid təsəvvür etmək faydalıdır. Sertifikat xarici kilidi açır, xidmətə görə verilən qərar isə daxili kilidi açır; heç biri digərini əvəz etmir. Yalnız xarici kilidi olan xidmət üzvlüyü heç tətbiq etmir, sadəcə autentifikasiya edir. Hər hansı dəyişiklik etməzdən əvvəl hər iki qərarı yazın, çünki yalnız işləyən bir qoşulmanın formasında mövcud olan siyasəti audit etmək mümkün deyil. Bundan sonrası daxili kiliddən bəhs edir.

Könüllü üstələmələri qəbul qapısına çevirin

Müştəri konfiqurasiya qovluğu adətən rahatlıqdır: içindəki fayllar adlarını çəkdikləri müştərilərin parametrlərini üstələyir və faylı olmayan müştəri sadəcə serverin susmaya görə dəyərləri ilə işləyir. Bir direktiv bu rahatlığı qapıya çevirir, belə ki faylın olmaması qoşulmanın rədd edilməsi deməkdir.

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

İcma buraxılışı OpenVPN 2.6 ccd-exclusive direktivini öz təlimat səhifəsində məhz bu şərt kimi sənədləşdirir və adlı fayl axtarışı effektiv müştəri kimliyinə əsaslanır. Digər buraxılışlar və məhsul tərəfindən idarə olunan serverlər fərqlənə bilər, ona görə də eyni semantikaya başqa yerdə güvənməzdən əvvəl quraşdırılmış versiyanı təsdiqləyin.

Yuxarıdakı yolu nümunə hesab edin və bələdçinin uydurduğu qovluq yaratmaq əvəzinə yerləşdirilmiş sxemi yoxlayın. Mövcud sertifikat yoxlamalarını, server kimliyi yoxlamalarını və hesab autentifikasiyasını olduğu kimi saxlayın, çünki fraqment şərt əlavə edir və heç nə çıxarmır. Dəyişikliyi istehsaldan əvvəl hazırlayın, çünki səhv nöqtədə qaldırılan rədd sertifikat nasazlığı kimi görünür və araşdırmanı orqana yönəldir. Sonra rədd edilən müştəri üçün jurnal sətrinin zənciri deyil, çatışmayan konfiqurasiya faylını göstərdiyini təsdiqləyin.

Hər xidmət üçün bir qovluq, bir ortaq siyahı deyil

Üzvlük onu tətbiq edən xidmətə aiddir, ona görə də hər xidmət öz qovluğunu və öz fayllarını saxlayır. İki xidməti bir siyahıya yönəltmək onları üzvlüyü paylaşmağa məcbur edir heç kim bunu istəməsə də, və yaranan dəyişikliyi hansısa qərara bağlamaq çətinləşir. Ortaq orqan ortaq qala bilər; qəbul faylları qala bilməz. Onları ayrı saxlamaq həm də o deməkdir ki, bir xidmətdəki səhv digərini səssizcə genişləndirə bilməz.

DEFAULT girişi insanları yanıldan haldır. O, adlı fayl tapılmadıqda ehtiyat parametrlər verir, lakin qapının tələb etdiyi adlı fayl deyil, ona görə də təkbaşına müştərini qəbul edə bilməz. Heç girişi olmayan müştərini sınayın və rəddi təsdiqləyin; əgər həmin müştəri qəbul edilirsə, ehtiyat tətbiq olunur və ccd-exclusive həmin instansiyada qüvvədə deyil.

Effektiv kimlik hansı faylın oxunacağını müəyyən edir

Axtarış müştərinin həqiqətən autentifikasiya etdiyi kimlikdən istifadə edir, bu da adətən sertifikatın ümumi adıdır. Server həmçinin istifadəçi adı və parolu yoxlayıb həmin adı ümumi ada çevirdikdə, fayl bunun əvəzinə autentifikasiya olunmuş istifadəçi adına uyğun olmalıdır. Uyğunsuzluq heç vaxt seçilməyən inandırıcı fayl adları ilə dolu bir qovluq qoyur.

Oxumaq digər yarıdır. Daemon adətən başladıqdan sonra imtiyazları buraxır, ona görə də azaldılmış hesabın qovluğa və onun hər girişinə oxuma icazəsi olmalıdır. Müştərilər hər hansı yazıla bilən yoldan öz girişlərini yarada bilməməlidir, çünki özünə xidmət qəbulu mexanizmi tamamilə sıradan çıxarır. Yalnız fayl rejimini deyil, montaj və paylaşma icazələrini də yoxlayın, çünki bir hesaba bağlı görünən qovluq digərinə açıq ola bilər. Sonra işləyən prosesin unit faylının qeyd etdiyi hesabı deyil, həqiqətən hansı hesabı istifadə etdiyini təsdiqləyin. Bu ikisi yalnız başqa heç nə onları dəyişmədikdə eyni olur.

Rəddi, qəbulu və ləğvi ayrı-ayrılıqda müşahidə edin

Xidmətə aid olan kimliyi sınayın və qoşulduğunu təsdiqləyin. Girişi olmayan etibarlı sertifikatı sınayın və rədd edildiyini təsdiqləyin. Digər xidmətə qəbul olunmuş kimliyi sınayın və burada qəbul edilmədiyini təsdiqləyin. Hər nəticənin yanında xidmət instansiyasını və effektiv kimliyi qeyd edin, çünki bu kontekst olmadan nəticəni başqa heç kim təkrarlaya bilməz.

Geri götürmə ləğvdən ayrı əməliyyatdır. Qəbul faylını redaktə etmək bir xidmət hüququnu silir, kimlik isə hər yerdə başqa yerdə qüvvədə qalır, halbuki kompromisə uğramış açar təşkilatın ləğv cavabını tələb edir. Artıq qurulmuş sessiyalara nə olacağını əvvəlcədən qərarlaşdırın, çünki nə qovluq redaktəsi, nə də ləğv siyahısı onları təkbaşına bitirmir.

Qəbul həm də yalnız ilk qapıdır. Bir xidmətə qoşulmaq arxasındakı subnetlər, verilənlər bazaları və ya idarəetmə interfeysləri barədə heç nə demir və həmin resurs siyasəti ayrıca yazılmalı və sınaqdan keçirilməlidir.