Один сертификат на устройство не привязывает ключ к устройству
Сертификат на каждое устройство — это административный выбор, а не привязка к устройству. Привязку определяет то, где находится закрытый ключ, от копируемого файла до TPM.
Вы выдаёте отдельный сертификат для каждого ноутбука, поэтому считаете, что VPN может их различить. Не может. Клиентский сертификат доказывает, что подключающийся владеет соответствующим закрытым ключом, а скопированный профиль тоже им владеет.
Сертификат на каждое устройство по-прежнему хорошая идея. Просто он выполняет другую работу, чем ожидает большинство.
Что на самом деле доказывает клиентский сертификат
Во время рукопожатия клиент подписывает закрытым ключом, который соответствует его сертификату, а сервер проверяет эту подпись по CA, которой доверяет. Ничто в этом обмене не описывает машину. Любое устройство, имеющее и сертификат, и ключ, создаёт одинаковую подпись, поэтому профиль, скопированный на второй ноутбук, выглядит точно как оригинал. Сертификат называет личность; он не называет аппаратуру.
Уникальность на каждое устройство по-прежнему оправдана, потому что делает отзыв точным. Это административное свойство, а не технический замок.
Три уровня хранения ключа
Первый уровень — файл ключа на диске. Он переносим по замыслу, и именно там живёт большинство профилей OpenVPN.
Второй уровень — ключ, который операционная система помечает как неэкспортируемый. Windows может создать ключ устройства в своём хранилище сертификатов и отказать в обычном экспорте, что останавливает случайное копирование. Он не опирается на аппаратуру, и при достаточном доступе к машине такие ключи можно восстановить, поэтому он повышает трудозатраты, а не строит стену.
Третий уровень — ключ, созданный внутри аппаратного модуля безопасности: TPM, смарт-карты, SIM или токена PIV. У этих модулей нет схем для экспорта созданного ими ключа, а подпись происходит внутри модуля. Ключ никогда не становится файлом, который кто-либо может скопировать.
| Where the key lives | Copyable | What it buys you |
|---|---|---|
| Key file inside the profile | Trivially | Revocation granularity, nothing more |
| OS non-exportable key store | Hard, not impossible | Stops casual profile sharing |
| TPM or PIV token | No | Binding the server can rely on |
Эта таблица — весь аргумент в трёх строках.
Что easy-rsa может и чего не может
Выдавать сертификаты на каждое устройство просто. Создайте отдельное общее имя для каждого устройства в рамках одной CA, например ./easyrsa build-client-full laptop-a nopass, и повторите для каждого устройства. Запишите, какое общее имя принадлежит какому человеку и машине.
Отзыв столь же прямой: ./easyrsa revoke laptop-a, пересоздайте CRL с помощью ./easyrsa gen-crl и убедитесь, что сервер действительно читает его через crl-verify.
Чего CA не может — проверить, где закрытый ключ находится потом. Если вы создаёте ключ на хосте CA и копируете его на устройство, при выдаче вы создали вторую копию. Неэкспортируемый ключ должен создаваться на устройстве или импортироваться в аппаратуру, которая его не отдаст.
Меры, которые переживают скопированный профиль
Считайте, что профиль можно скопировать, и проектируйте соответственно. Привяжите учётную запись ко второму фактору, чтобы одного сертификата было недостаточно. Дайте каждому устройству свою политику, чтобы охват одной личности оставался ограниченным. И следите за одним и тем же общим именем, подключающимся с двух адресов одновременно, потому что именно так выглядит общий профиль в журнале подключений.
Быстрый и документированный отзыв — это мера, которая продолжает работать после того, как копия уже сделана. Всё остальное — профилактика.
Утверждение, на которое сервер действительно может опереться
Уникальность исходит от CA. Привязка к устройству исходит от хранения ключа. Только аппаратура, которая не может экспортировать свой ключ, превращает один сертификат на устройство в утверждение, которое сервер обеспечивает, а не в политику, с которой все согласны.