Спільний CA, окремі двері: одна служба на файл допуску

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

Довірений ланцюжок нічого не каже про членство в службі

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

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

Перетворіть необов'язкові перевизначення на шлюз допуску

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

client-config-dir /etc/openvpn/service-a/clients
ccd-exclusive

Громадська збірка OpenVPN 2.6 ccd-exclusive документує на своїй сторінці посібника саме цю умову, а пошук названого файлу залежить від фактичної особи клієнта. Інші збірки й сервери під керуванням продуктів можуть відрізнятися, тож перевірте встановлену версію, перш ніж покладатися на ту саму семантику в іншому місці.

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

Один каталог на службу, а не один спільний список

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

Запис DEFAULT — це випадок, який вводить людей в оману. Він дає резервні налаштування, коли названого файлу не знайдено, але це не той названий файл, якого вимагає шлюз, тож сам він не може допустити клієнта. Перевірте клієнта, який узагалі не має запису, і підтвердьте відмову; якщо такий клієнт допускається, застосовується резерв і ccd-exclusive у цьому екземплярі не діє.

Фактична особа вирішує, який файл читається

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

Читання — друга половина. Демон зазвичай скидає привілеї після запуску, тож зменшеному обліковому запису потрібен доступ на читання до каталогу й кожного запису в ньому. Клієнти не повинні мати змоги створювати власний запис через будь-який шлях із правом запису, бо допуск за самозаписом повністю знецінює механізм. Перевірте права монтування й спільного доступу, а не лише режим файлу, оскільки каталог, закритий для одного облікового запису, може бути відкритим для іншого. Потім з'ясуйте, який обліковий запис справді використовує запущений процес, а не який згадує unit-файл. Ці два збігаються лише тоді, коли ніщо інше їх не змінювало.

Спостерігайте відмову, допуск і відкликання окремо

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

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

Допуск — це також лише перший шлюз. Приєднання до служби нічого не каже про підмережі, бази даних чи інтерфейси керування за нею, і ця політика ресурсів має бути написана й перевірена окремо.