Дръжте ключа за подпис на CA на OpenVPN извън /etc/openvpn

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

Какво съдържа работното пространство на CA

Директорията на PKI е състояние на издателя, не конфигурация. Тя съдържа частния ключ и сертификата на CA, файл за серийните номера, индекс на издадените сертификати и материала за всяка идентичност, произведен от тях.

Подписването на заявка променя това състояние, затова работното пространство принадлежи на акаунт под административен контрол на хост, където услугата VPN не работи. Всеки, който може да прочете частния ключ на CA, може да издаде сертификат, на който сървърът ще се довери, така че защитата на ключа е целият модел на доверие в един файл. Копирането му на второ място, за да се спести стъпка, създава второ нещо за защита и второ нещо за забравяне. Всеки подпис също увеличава серийния номер и добавя запис към индекса, затова работното пространство е едно копие на състоянието, а не папка с файлове.

Публичният сертификат на CA е различен. Той е предназначен за разпространение и с него клиентите и сървърите се проверяват взаимно.

Какво чете демонът при стартиране

Работещият сървър консумира малък набор: собствения си сертификат, собствения си частен ключ, сертификата на CA за проверка на партньорите и какъвто ключов материал изисква избраният режим. Той чете тези пътища при стартиране и отново при презареждане.

Собствеността трябва да се оценява спрямо юнита, който действително стартира, а не спрямо интерактивен root shell. Обявената изолация може да направи част от файловата система само за четене или невидима, дори когато ръчен тест като root успее.

systemctl show -p User -p Group -p ReadOnlyPaths [email protected]
stat -c '%a %U:%G' /etc/openvpn/server/server.key
runuser -u openvpn -- test -r /etc/openvpn/server/server.key; echo $?

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

Двата пътя на отказ заслужават разделяне, преди да промените каквото и да е право. Отказът при подписване сочи към директорията на PKI, правото за търсене в родителските ѝ директории и акаунта, който изпълнява издателя. Отказът при стартиране сочи към юнита, работната му директория и пътищата, посочени в конфигурацията на сървъра. Правенето на цялото дърво четим за всички не поправя нито едно от двете и премахва границата, на която и двете разчитат.

Защо копирането на ключа на CA на сървъра се проваля по-късно

Копието обикновено започва като ход за отстраняване на грешки: някой иска да поднови клиент на хоста на VPN, така че ключът на CA попада в /etc/openvpn и подновяването минава. Непосредствената задача успява, а границата я няма.

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

Възстановяването от това състояние не е въпрос на изтриване на файл. Трябва да решите дали ключът е бил изложен, да смените CA, ако е бил, и да разпределите доверието наново към всеки партньор. Отделно работно пространство избягва целия този разговор.

Акаунти, директории, резервни копия

Дайте на издателя собствен акаунт и домашна директория, държани извън хоста на VPN, където това е практично. Дайте на демона различен акаунт, с достъп за четене до разгърнатия материал и без достъп за запис до нищо, което издава сертификати. Внедрявайте, като копирате публични сертификати навън и никога като дърпате частното състояние на издателя навътре. Правете резервни копия на двете роли поотделно, защото тяхната чувствителност и истории на възстановяване се различават.

След отнемане актуализирайте CRL файла, който конфигурацията на сървъра посочва, после презаредете услугата, за да го прочетат новите връзки. Документацията на Easy-RSA описва оформлението на работното пространство и работния процес по подписване; правилата за собственост около него остават решение за вашия хост. Потвърдете какво е заредила услугата с openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate, вместо да предполагате, че презареждането го е поело.

Тест, който доказва разделението

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

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