Зошто клучевите на серверот и акредитивите на корисникот бараат одделни сопственици

Клучот што докажува дека вашата порта е таа самата и акредитивот што вели дека некое лице може да се приклучи се и двете тајни и тука сличноста завршува. Едниот идентификува услуга пред секој клиент; другиот идентификува еден корисник пред таа услуга. Нивното мешање заштедува еден чекор при поставување и чини едно попладне за време на инцидент, бидејќи обновувањето за секој од нив не е иста операција. Одвојувањето е досадно за поставување и незаборавно кога се прескокнува.

Две тајни, два различни сопственици

Портата држи приватен клуч или сертификат чија единствена задача е да го докаже својот идентитет при ракувањето. Клиентите го бараат соодветниот јавен материјал за да го проверат и никогаш не им треба приватната половина. Токму таа асиметрија ја овозможува автентикацијата на серверот без да му се даде на секој корисник можност да се претставува како серверот.

Материјалот на корисникот оди во спротивна насока. Приватен клуч на клиент, клиентски сертификат или лозинка покажуваат дека токму на ова лице или уред му е доделен пристап. Се очекува да се дистрибуира, копира меѓу уреди и на крајот да се отповика.

WireGuard го прави одвојувањето очигледно бидејќи секој учесник има пар клучеви: приватниот клуч на серверот останува на серверот, а конфигурациската датотека што му ја давате на корисникот ги содржи неговиот сопствен приватен клуч плус јавниот клуч на серверот. Профилот што го содржи приватниот клуч на серверот не е кратенка, туку компромис што чека споделување датотека.

Три прашања што го одлучуваат одвојувањето

Прашајте кој мора да може да ја чита тајната, што би му овозможило изложувањето на напаѓачот и дали решението е едно отповикување или повторно градење на услугата.

Ако корисникот може да ја чита и таа го докажува идентитетот на портата, одговорот на второто прашање е дека напаѓачот може да се претставува како вашиот сервер пред секој клиент — најлошиот исход, бидејќи клиентите се создадени да му веруваат на тој идентитет. Ако докажува само еден корисник, изложувањето му дава пристап на тој корисник до еден партнер, а отповикувањето е рутинска операција. Ако е клуч на сертификациски орган, изложувањето е полошо од двете, бидејќи напаѓачот може да создаде идентитети во кои верува секоја крајна точка.

Тие три одговори го даваат правилото за чување: CA клучот живее офлајн или во сеф, клучот на портата живее на портата, а корисничките клучеви живеат кај корисниците. Секој распоред што сите три ги става во една папка за удобност го претворил решението во несреќа.

Што навистина му треба на клиентот

На клиентот му требаат јавниот сертификат или јавниот клуч на партнерот, CA материјалот или отпечатокот на кој треба да му верува, неговиот сопствен приватен клуч и деталите за крајната точка. Тој список не содржи ништо што и припаѓа на приватната идентичност на портата.

Документацијата е каде што ова протекува. Водичот што вели копирајте ја папката на серверот и избришете што не ви треба веќе го научил погрешниот модел, бидејќи датотеката што останува по чекорот на бришење ретко ја проверува некој.

Отповикајте еден корисник без да ја допрете портата

Бидејќи корисничките идентитети се издаваат одделно, тие можат да се повлечат одделно. Распоредувањето засновано на сертификати го отповикува клиентскиот сертификат и објавува ажуриран список за отповикување; распоредувањето со WireGuard го отстранува записот за партнерот од конфигурацијата на серверот. Ниту една од тие операции не го менува сопствениот клуч на портата.

Чувајте го записот за издавање, инаку нема да знаете кој идентитет да го повлечете. Табела е доволна, под услов да ги наведува лицето, уредот, серискиот број или јавниот клуч и датумот, и под услов некој да ја одржува откако лицето што ја изградило ќе замине.

Командите подолу проверуваат клиентски сертификат и потоа го отповикуваат преку орган во стил на OpenSSL, што е текот што го завиткува easy-rsa:

openssl x509 -in client.crt -noout -subject -serial
openssl ca -config openssl.cnf -revoke client.crt
openssl ca -config openssl.cnf -gencrl -out crl.pem

Објавете го новиот список таму каде што клиентите го проверуваат, инаку отповикувањето е белешка во датотека што ништо не менува. Ако вашата порта прифаќа клиентски сертификати без да го провери списокот за отповикување, кажете го тоа експлицитно наместо да навестувате дека отповикувањето работи.

Чувајте ги резервните копии онолку одвоени колку и тајните

Архивата за повторно градење законски ги содржи клучот на портата и CA материјалот, бидејќи без нив обновувањето не може да ја репродуцира услугата. Пакетот за поставување на клиент не смее, и двете не смеат да се чуваат заедно. Означете ја секоја архива според тоа кој смее да ја чува, а не според датумот кога е направена. Токму таа ознака ја чита уморен администратор во два часот навечер.

Таа разлика исто така одредува кој смее да го преземе секој од нив. Управувањето со портата, издавањето кориснички идентитети и читањето резервни копии се три различни овластувања, а на оној кому му треба едното не му требаат автоматски другите. Запишете ги тие дозволи и потоа проверете ги спрема тоа што вашето складиште навистина го дозволува, бидејќи наследувањето папки тивко дава повеќе отколку што политиката предвидува.