Къде трябва да живее частен ключ за VPN: файл, CNG или TPM?

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

Изберете между копиране и използване

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

Ключ във файл се копира тривиално, поради което е и най-лесният за архивиране и възстановяване. Софтуерно хранилище за ключове променя API, а не границата: доставчикът отказва собствените си извиквания за експорт, но същият администраторски контекст, който е инсталирал ключа, обикновено има други пътища до материала. Неекспортируем при софтуерен доставчик е твърдение за поддържани операции, а не доказателство за хардуерна стена. Третирайте го като ограничител срещу случайно копиране, не като защита срещу някой, който вече държи сесията ви.

TPM или смарт карта изпълнява операцията по подписване в хардуера и връща само резултата. Това затваря пътя за копиране и оставя пътя за използване отворен за всичко, което може да поиска подпис.

Съгласувайте хранилището с демона на тунела

Демонът ограничава това повече, отколкото политиката за сигурност. WireGuard приема частен ключ в base64 от файл или от входа на wg set и няма път към хранилище за сертификати, така че ключ на интерфейс с поддръжка на TPM не е на масата. OpenVPN, компилиран срещу OpenSSL 3, може да зареди ключ чрез URI на доставчик, а strongSwan доставя TPM плъгин редом с поддръжка на PKCS#11, но и двете зависят от това как е компилиран пакетът ви.

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

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

Направете инвентар на ключа преди преместване

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

openssl x509 -in vpn.crt -noout -subject -ext subjectAltName
openssl pkey -in vpn.key -check -noout
openssl x509 -in vpn.crt -noout -pubkey | openssl sha256
openssl pkey -in vpn.key -pubout | openssl sha256

Последните два дайджеста трябва да са идентични. Ако не са, демонът завършва настройката и след това се проваля при всеки опит с грешка за сертификат или подпис, която не сочи никъде близо до истинската причина. Еквивалентът за WireGuard е по-кратък, защото публичният ключ се извежда директно от частния: wg pubkey < /etc/wireguard/wg0.key трябва да отпечата ключа на партньора, който вашият сървър вече съхранява.

Правата принадлежат към същия инвентар. stat -c '%a %U:%G' /etc/wireguard/wg0.key трябва да върне 600 root:root, а всичко, което е четимо за групата или света, означава, че ключът вече е бил достъпен за процеси, които не сте предвиждали.

Проверете хранилището и пътя за използване

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

certutil -store -user My
certutil -csp "Microsoft Platform Crypto Provider" -key -user
certutil -verifykeys -user My
ipsec listcerts

В Windows първата команда изброява личното хранилище и отпечатва доставчика на ключа до всеки запис и там се появява сертификат, който изглежда хардуерно защитен, но седи в софтуерния доставчик. Втората изброява ключове, държани от платформения криптодоставчик, така че идентичност на VPN, липсваща там при наличен сертификат, означава, че частната половина живее другаде. На Linux шлюз ipsec listcerts отчита какво е заредил strongSwan, включително ключове от TPM плъгина. Сравнявайте отпечатъци или хешове на публични ключове с инвентара, вместо да разчитате на броя записи.

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

Запишете подновяването и връщането назад

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

Проверявайте изтичането, преди да се превърне в прекъсване: openssl x509 -in vpn.crt -noout -checkend 2592000 завършва с ненулев код, когато сертификатът изтече в рамките на тридесет дни, така че се вписва директно в проверка за мониторинг. Седмично изпълнение на този ред хваща подновяването, което никой не е планирал.

Премахването се извършва на сървъра: изтрийте партньора или отменете серийния номер, след което потвърдете, че тунелът се проваля, тъй като клиент с кеширана сесия може да скрие наполовина завършено отменяне за известно време. Отменянето трябва да достигне и до пътя CRL или OCSP на концентратора, не само до базата данни на CA. Сертификатът е публичен документ и профилът RFC 5280 описва как се валидира; нищо в тази валидация не защитава частен ключ, копиран преди ротацията.

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