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

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

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

Вирішіть, яку здатність ви надаєте

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

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

Проміжний сертифікат обмежує повноваження

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

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

pathLen нуль означає не те, що ви думаєте

RFC 5280 розділ 4.2.1.9 визначає базові обмеження, і його поле довжини шляху обмежує, скільки несамовиданих проміжних сертифікатів може слідувати в допустимому шляху. Значення нуль обмежує подальшу проміжну глибину; воно не обмежує кількість сертифікатів кінцевих суб'єктів. Люди читають це як нуль дозволених сертифікатів і потім дивуються, чому випуск досі працює. Читайте поле як обмеження глибини для CA, і поведінка стає передбачуваною.

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

Звільнення — це не компрометація ключа

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

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

Прийміть проєкт із чотирма конкретними випадками: відповідний пристрій реєструється, незатверджений запит відхиляється, видалений оператор більше не може видавати, а виведений видавець більше не надає доступу. Ці чотири результати і є runbook.