Блок-лист Nebula: поширюйте його самі, маяк цього не зробить

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

Що насправді робить запис у блок-листі

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

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

Ідентифікуйте сертифікат, а не пристрій

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

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

nebula-cert print -path /etc/nebula/host.crt
pki:
  blocklist:
    - "a1b2c3d4e5f6"

Поширюйте його як будь-яку іншу конфігурацію

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

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

Блок-лист чи ротація органу

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

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

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

Перевірте відмову та решту

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

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