Почему ключи сервера и учётные данные пользователей должны иметь разных владельцев

Ключ, доказывающий, что ваш шлюз — это он сам, и учётные данные, говорящие, что человек может подключиться, оба являются секретами, и на этом сходство заканчивается. Один идентифицирует сервис перед каждым клиентом; другой идентифицирует одного пользователя перед этим сервисом. Их смешение экономит шаг при настройке и стоит полдня во время инцидента, потому что восстановление для каждого — не одна и та же операция. Разделение скучно настраивать и запоминается, если его пропустить.

Два секрета, два разных владельца

Шлюз хранит закрытый ключ или сертификат, единственная задача которого — доказать свою идентичность во время рукопожатия. Клиентам нужен соответствующий открытый материал для проверки, а закрытая половина им не нужна никогда. Именно эта асимметрия делает возможной аутентификацию сервера, не давая каждому пользователю возможности выдавать себя за сервер.

Материал пользователя движется в обратную сторону. Закрытый ключ клиента, клиентский сертификат или пароль показывают, что именно этому человеку или устройству был выдан доступ. Предполагается, что он будет распространяться, копироваться между устройствами и в конце концов отозван.

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, потому что без них восстановление не может воспроизвести сервис. Пакет настройки клиента не должен, и эти два нельзя хранить вместе. Помечайте каждый архив по тому, кому можно его держать, а не по дате создания. Именно эту пометку читает уставший администратор в два часа ночи.

Это различие также определяет, кто может получить каждый из них. Администрирование шлюза, выдача идентичностей пользователей и чтение резервных копий — три разные полномочия, и тому, кому нужно одно, не обязательно нужны другие. Запишите эти разрешения, а затем проверьте их по тому, что на самом деле позволяет ваше хранилище, потому что наследование каталогов молча даёт больше, чем предполагает политика.