Вы выдаяце асобны сертыфікат для кожнага ноўтбука, таму лічыце, што VPN можа адрозніць іх. Не можа. Кліенцкі сертыфікат даказвае, што той, хто падключаецца, мае адпаведны прыватны ключ, а скапіяваны профіль таксама мае яго.

Сертыфікат на кожную прыладу ўсё яшчэ добрая ідэя. Проста ён выконвае іншую працу, чым большасць людзей чакае.

Што насамрэч даказвае кліенцкі сертыфікат

Падчас рукапаціскання кліент падпісвае прыватным ключом, які адпавядае яго сертыфікату, а сервер правярае гэты подпіс супраць CA, якому давярае. Нішто ў гэтым абмене не апісвае машыну. Любая прылада, якая мае і сертыфікат, і ключ, стварае ідэнтычны подпіс, таму профіль, скапіяваны на другі ноўтбук выглядае сапраўды як арыгінал. Сертыфікат называе ідэнтычнасць; ён не называе абсталяванне.

Унікальнасць на кожную прыладу ўсё яшчэ апраўдана, бо робіць адкліканне дакладным. Гэта адміністрацыйная ўласцівасць, а не тэхнічны замок.

Тры ўзроўні захавання ключа

Першы ўзровень — файл ключа на дыску. Ён пераносны па задуме, і менавіта там жывуць большасць профіляў OpenVPN.

Другі ўзровень — ключ, які аперацыйная сістэма пазначае як неэкспартуемы. Windows можа стварыць ключ прылады ў сваім сховішчы сертыфікатаў і адмовіць у звычайным экспарце, што спыняе выпадковае капіяванне. Ён не падмацаваны абсталяваннем, і пры дастатковым доступе да машыны такія ключы можна аднавіць, таму гэта павялічвае намаганні, а не будуе сцяну.

Трэці ўзровень — ключ, створаны ўнутры апаратнага забеспячэння бяспекі: TPM, разумная картка, SIM або токен PIV. Гэтыя модулі не маюць схем для экспарту створанага імі ключа, і подпіс адбываецца ўнутры модуля. Ключ ніколі не робіцца файлам, які хтосьці можа скапіяваць.

Where the key livesCopyableWhat it buys you
Key file inside the profileTriviallyRevocation granularity, nothing more
OS non-exportable key storeHard, not impossibleStops casual profile sharing
TPM or PIV tokenNoBinding 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. Прывязка да прылады — ад захавання ключа. Толькі абсталяванне, якое не можа экспартаваць свой ключ, ператварае адзін сертыфікат на прыладу ў сцвярджэнне, якое сервер прымяняе, а не ў палітыку, з якой усе згаджаюцца.

Падобныя артыкулы