Один CSR — ще не реєстрація: що має перевірити CA для VPN

Запит на підпис сертифіката містить відкритий ключ і запитаний subject, підписані відповідним закритим ключем. Цей підпис доводить, що заявник володіє ключем. Він не доводить, що заявник має право на запитане ім'я, пристрій або роль у VPN, і ставлення до запиту так, ніби він це доводить, — саме так тікет до служби підтримки перетворюється на надання доступу.

Дві моделі реєстрації варто порівнювати за тим, що вони зв'язують, а не за тим, яким протоколом вони говорять.

Запит заявляє ім'я, але не доводить його

Читайте запит за тим, що в ньому справді є: відкритий ключ, обраний заявником subject і власний підпис над обома. Ніщо в цій структурі не посилається на ваш інвентар, каталог облікових записів або процес погодження. Subject на кшталт cn=finance-laptop — це рядок, який хтось набрав. Доки процес видачі не звірить цей рядок із записом, якому довіряє, сертифікат залишається твердженням із доданим підписом. Ця відмінність і є вся причина існування процесу реєстрації.

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

Порівняйте моделі за тим, що вони зв'язують

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

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

Обирайте модель за кількістю очікуваних реєстрацій і за змінністю пристроїв. Кілька серверів на рік переживуть ручну перевірку з письмовим контрольним списком. Парк ноутбуків — ні.

Фіксуйте життєвий цикл від першої видачі

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

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

Перевірте виданий сертифікат, потім доступ

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

openssl req -in client.csr -noout -verify -subject
openssl x509 -in client.crt -noout -subject -issuer -dates -ext extendedKeyUsage
openssl verify -CAfile ca.crt client.crt

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

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