Защо ключовете на сървъра и данните за вход на потребителите изискват различни собственици

Ключът, който доказва, че вашият шлюз е самият той, и данните за вход, които казват, че човек може да се присъедини, са и двете тайни и точно тук приликата свършва. Едното идентифицира услуга пред всеки клиент; другото идентифицира един потребител пред тази услуга. Смесването им спестява една стъпка при настройката и струва един следобед при инцидент, защото възстановяването за всяко от тях не е една и съща операция. Разделението е скучно за настройка и се помни, когато се пропусне.

Две тайни, двама различни собственици

Шлюзът държи частен ключ или сертификат, чиято единствена задача е да докаже самоличността си по време на ръкостискането. Клиентите се нуждаят от съответния публичен материал, за да го проверят, и никога не се нуждаят от частната половина. Именно тази асиметрия прави удостоверяването на сървъра възможно, без да дава на всеки потребител способността да се представя за сървъра.

Материалът на потребителя е в обратната посока. Частен ключ на клиент, клиентски сертификат или парола показват, че точно този човек или устройство е получило достъп. Очаква се той да се разпространява, да се копира между устройства и в крайна сметка да бъде отнет.

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, защото без тях възстановяването не може да възпроизведе услугата. Пакетът за настройка на клиент не трябва, и двете не бива да се съхраняват заедно. Етикетирайте всеки архив според това кой може да го държи, а не според датата на създаване. Този етикет е това, което изморен администратор чете в два часа през нощта.

Това разграничение определя и кой може да извлече всяко от тях. Администрирането на шлюза, издаването на потребителски идентичности и четенето на резервни копия са три различни правомощия и човек, на когото е нужно едното, не се нуждае автоматично от другите. Запишете тези разрешения и след това ги проверете срещу това, което вашето хранилище всъщност позволява, защото наследяването на директории тихо дава повече, отколкото политиката предвижда.