Чому ключі сервера та облікові дані користувачів потребують різних власників

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

Два секрети, два різні власники

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

Матеріал користувача — це інший напрямок. Закритий ключ клієнта, клієнтський сертифікат або пароль демонструє, що саме цій людині чи пристрою видано доступ. Очікується, що його розповсюджуватимуть, копіюватимуть між пристроями і зрештою відкличуть.

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, бо без них відновлення не може відтворити службу. Пакунок налаштування клієнта не повинен їх містити, і ці два не можна зберігати разом. Позначайте кожен архів за тим, хто може його тримати, а не за датою створення. Саме цю позначку втомлений адміністратор читає о другій годині ночі.

Ця відмінність також визначає, хто може отримати кожен із них. Адміністрування шлюзу, видача ідентичностей користувачів і читання резервних копій — це три різні повноваження, і людина, якій потрібне одне, не потребує автоматично інших. Запишіть ці дозволи, а потім перевірте їх проти того, що насправді дозволяє ваше сховище, бо успадкування каталогів тихо дає більше, ніж задумує політика.