Всі сервери. Всі підписи. Всі користувачі. Всі пристрої...
Усе керується на одній платформі !
Вся сім'я PKI під одним дахом !

15 кроків для налаштування власного центру сертифікації

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

Дані опитування вказують на те, що більше половини організацій визнають, що вони не дотримуються найкращих практик керування ключами щодо зберігання своїх криптографічних ключів на апаратних модулях безпеки (HSM) . Але створення та зберігання криптографічних ключів на HSM є лише одним із багатьох передових практик кібербезпеки приватного ЦС, яких компанії повинні дотримуватися, захищаючи свою внутрішню інфраструктуру та дані за допомогою інфраструктури відкритих ключів (PKI) .

Чому самопідписані та загальнодоступні сертифікати ЦС не допоможуть у приватній PKI

Чи можете ви використовувати самопідписані сертифікати або сертифікати загальнодоступного ЦС для захисту ваших внутрішніх мереж? Відповідь — однозначне НІ — і це так з кількох ключових причин:

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

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

Налаштування приватного центру сертифікації: це можна зробити двома способами

Варіант №1: налаштуйте власний приватний ЦС

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

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

Отже, що саме передбачає створення приватного ЦС? Ось короткий огляд:

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

Але побудова приватного ЦС з нуля не для всіх. І тому ми маємо альтернативний підхід…

Варіант №2: виберіть рішення для керованого PKI (mPKI) для вашого приватного ЦС

Керований приватний ЦС, або керований PKI (mPKI), є більш економічно ефективним варіантом у довгостроковій перспективі. Для цього потрібно менше авансових і поточних фінансових ресурсів з точки зору ІТ-обладнання, персоналу та операційних витрат. Digicert PKI забезпечує кращий захист для вас і вашої компанії, оскільки постачальник послуг керує операційними процесами та керуванням, і ви не повинні самі вирішувати, як виправити речі, які інакше пішли б не так.

DigiCert Trust Lifecycle Manager - це комплексне розміщене рішення, яке дає вам змогу масштабно керувати життєвими циклами ваших приватних цифрових активів PKI. Це кероване рішення PKI, яке інтегрується з існуючими архітектурами багатьох організацій. Використання керованого приватного ЦС також дає змогу пропустити більшість завдань, пов’язаних із налаштуванням власного центру сертифікації, оскільки більшість цих функцій виконується за вас. Ваші мережеві пристрої та дані безпечні настільки, наскільки безпечні заходи, які ви вживаєте. А погано реалізований приватний ЦС такий же корисний, як і відсутність приватного PKI взагалі.

Якщо ви вирішите піти шляхом «Зроби сам», вам потрібно буде виконати кілька кроків, щоб запустити та запустити свій приватний центр сертифікації.

1. Виберіть програмну платформу для керування PKI
Під час налаштування власного центру сертифікації вам потрібно буде вибрати програмний інструмент, який дозволить вам керувати вашим приватним PKI. Багато організацій, які використовують системи Microsoft, вибирають використання Microsoft CA через Microsoft Active Directory Certificate Services (AD CS), оскільки це дозволяє використовувати AD. Microsoft CA — це «диявол, якого ви знаєте»; він чудово інтегрується з інструментами та службами сторонніх виробників і чудово підходить для локального розгортання. Інші популярні альтернативи Microsoft CA з відкритим кодом включають:
Утиліта OpenSSL: OpenSSL — це досить просте рішення, яке підходить для запуску та керування невеликими PKI. Але якщо ви плануєте мати більше, ніж просто декілька сертифікатів, вам буде краще використовувати більш комплексну систему керування PKI.
EJBCA: Раніше називався Enterprise Java Beans Certificate Authority , цей інструмент із відкритим вихідним кодом є більш надійним і масштабованим варіантом для видачі сертифікатів, перевірки та керування ними, ніж його утиліта OpenSSL.

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

3. Налаштуйте безпечне середовище для своїх офлайнових (кореневих) і онлайнових (випускних) ЦС
Цей крок у створенні власного центру сертифікації полягає в тому, щоб розставити «Т» і «І» щодо безпеки. Ви повинні застосувати поєднання фізичних і цифрових заходів безпеки, щоб захистити свою приватну екосистему ЦС від якомога більшої кількості векторів атак.

Заходи фізичної безпеки

• Запровадити розподіл обов’язків і подвійну автентифікацію для доступу та виконання будь-яких операцій, пов’язаних із кореневим ЦС.
• Адмініструвати заходи фізичної безпеки (доступ до ID-картки, фізично замкнені клітки, блокувальники USB-портів, камери, датчики руху, цілодобовий моніторинг доступу, озброєна охорона тощо). Ми також поговоримо про це далі в статті під час обговорення того, як захистити свій довірений root.
• Використовуйте онлайн-апаратний модуль безпеки (HSM), щоб безпечно генерувати та зберігати ваші проміжні онлайн-ключі або закриті ключі ЦС, що видають. Це робить ключі доступними для криптографічних операцій без надання до них прямого доступу.
  • Використовуйте пристрої HSM, сумісні зі стандартом FIPS 140-2 рівня 2 або вище, для кореневого ЦС і центру сертифікації.
  • Обов’язково клонуйте свої особисті ключі та зберігайте їх на двох або більше HSM (одного виробника та моделі). Ніколи не буде гарною ідеєю мати робочий ключ, який не має безпечної резервної копії, до якої можна повернутися
• Кореневі центри сертифікації: зберігайте ці захищені резервні копії в окремих географічних місцях, в ідеалі за сотні миль одне від одного, у захищених центрах обробки даних. Це забезпечить додатковий захист, якщо щось піде не так в одному географічному регіоні (скажімо, ураган, лісова пожежа чи інші фізичні загрози), гарантуючи, що у вас є одна або кілька безпечних резервних копій.
• ICA: зберігайте онлайнові та офлайнові резервні копії вашого проміжного або емітентного ЦС однаково.

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

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

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

• Встановіть пароль або PIN-код. Налаштування безпечного пароля (або, в ідеалі, парольної фрази) додає ще один рівень безпеки до вашого ключа, щоб запобігти його використанню для створення кореневого сертифіката ЦС без вашого відома чи авторизації. Це базовий рівень безпеки автентифікації FIPS 140-2 рівня 2 і вище. (Чим вищий рівень сертифікації FIPS пристрою, тим більше додаткових вимог до безпеки та автентифікації додається до нього, крім простого пароля, наприклад використання маркера доступу, ідентифікаційної картки доступу або біометричного механізму.)
• Виберіть алгоритм ключа кореневого ЦС. Хоча технічно ви не зобов’язані дотримуватися стандартів безпеки керування ключами Національного інституту стандартів і технологій (NIST) для розгортання PKI , вони все одно є хорошою базовою лінією, якої ви можете дотримуватися, щоб досягти принаймні мінімальної безпеки для вашої внутрішньої інфраструктури закритих ключів. Наприклад, розгляньте можливість використання RSA 2048 як абсолютного мінімуму.
• Налаштуйте поля розрізнених імен. Це включає інформацію про нашу організацію, зокрема ваше загальне ім’я (CN), назву організації, інформацію про місце розташування тощо.
• Встановіть параметри сертифіката. Це включає назву ЦС і терміни дії сертифікатів, які він видає.

Для приватного кореневого ЦС ключ необхідно створити та зберегти на захищеному HSM, який відповідає стандарту FIPS 140-2 рівня 2 (як мінімум). Порівняйте це з загальнодовіреним центром сертифікації, який має використовувати HSM FIPS 140-2 рівня 3 або вищого для свого кореня довіри відповідно до базових вимог галузі.

5. Створіть проміжний сертифікат ЦС і пару ключів і захистіть їх за допомогою унікальної парольної фрази
Тепер ця наступна частина налаштування належної архітектури PKI передбачає створення проміжного ЦС для відокремлення кореневого ЦС і сертифікатів кінцевих точок, які зв’язуються з ним. (ПРИМІТКА. Підпорядкований ЦС може бути або проміжним ЦС, або ЦС, що видає.)

Щоб забезпечити безпеку ключа, ви створите та збережете його в онлайновому HSM. Як і у випадку з кореневим центром сертифікації, ви захочете створити одну або кілька резервних копій (клонів ключа) і зберегти їх на одному виробнику та моделі HSM. Але на відміну від кореневого ЦС, ICA має бути доступним (онлайн) для підпису сертифікатів, відповідей OCSP і CRL. У дворівневій ієрархії ЦС , яка є найпоширенішою, цей підлеглий ЦС зазвичай називають центром сертифікації видачі

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

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

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

Хорошим емпіричним правилом є зберігання вашого кореневого ключа CA в автономному HSM, який зберігається в безпечному заблокованому середовищі. Організації часто використовують картки-ключа на основі PKI, щоб обмежити доступ до кімнати, а також датчиків руху та камер для виявлення та запису дій усередині та за межами цього простору. Подумайте про фізичні заходи безпеки, які ми згадували в кроці №1 для ICA. Але для кореневих центрів сертифікації візьміть цю безпеку та переключіть її на вищу передачу. Тому обов’язково клонуйте свій кореневий ЦС в режимі офлайн у двох або більше HSM, які зберігаються у фізично безпечних середовищах у різних географічних місцях. Подумайте про екранування своїх кабелів і впровадження блокувальників портів USB. Суть тут полягає в тому, щоб додати якомога більше рівнів захисту до вашого кореневого ЦС, щоб уберегти його від ризиків компрометації.

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

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

• Оператор або адміністратор резервного копіювання:
  ця роль відповідає за забезпечення наявності принаймні однієї поточної резервної копії бази даних ЦС (в ідеалі, кілька копій для забезпечення надлишковості) і відновлення даних у разі, якщо щось піде не так.
• Адміністратор ЦС:
  ця особа керує доступом до ЦС, механізмами відкликання сертифікатів і процесами, залученими до видачі сертифікатів. Ця позиція перекриває наступні дві у списку; у деяких організаціях адміністратор ЦС може виконувати всі три ролі).
• Агент реєстрації:
  ця роль керує шаблонами сертифікатів і реєстрацією сертифікатів для авторизованих користувачів.
• Менеджер із відновлення ключів:
  ця особа відповідає за все, що стосується архівування та відновлення криптографічних закритих ключів.
• Менеджер сертифікатів:
  ця особа відповідає за керування життєвими циклами ваших цифрових сертифікатів і криптографічних ключів.
• Аудитор безпеки:
  робота цієї особи полягає в перегляді журналів аудиту ЦС, щоб переконатися, що сертифікати видаються та відкликаються відповідно до політики ЦС.

8. Укажіть, як ЦС видаватиме та скасовуватиме цифрові сертифікати

• Профілі та типи сертифікатів. Тут ви налаштовуєте спеціальні профілі сертифікатів (шаблони сертифікатів) для певних типів випадків використання та груп користувачів. Наприклад, спеціальні або кінцеві сертифікати TLS, сертифікати автентифікації кінцевого клієнта, сертифікати підпису коду, сертифікати ЦС, сертифікати підпису документів, сертифікати підпису та шифрування електронної пошти тощо)
• Правила документування та процеси перевірки та видачі сертифікатів. Це одна з прекрасних (і обтяжливих) частин роботи приватного центру сертифікації: у вас є можливість запроваджувати власні правила та процеси щодо підтвердження та видачі сертифікатів. Хочете, щоб кожен сертифікат містив ключову інформацію? Без проблем. Просто додайте це як правило і продовжуйте свій день.
• Налаштуйте надійні письмові політики сертифікатів. Політика щодо сертифікатів містить заяву про надійність і застосовність цифрових сертифікатів, які видає ЦС. Це стосується сертифікатів як загальнодовірених, так і приватних ЦС.
• Визначте ключові типи, які ви дозволите у своїй політиці випуску. Визначте, які типи ключів ви хочете підтримувати — наприклад, RSA, ECC, ECDSA — для використання у вашій приватній PKI.

Приклад політик сертифікатів, викладених у кореневому сертифікаті ЦС DigiCert. CP з ідентифікатором об’єкта політики (OID) 2.23.140.1.3 відноситься до сертифікатів підпису коду EV. OID політики 2.16.840.1.114412.2.1 посилається на специфічний для DigiCert тип перевірки EV.

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

10. Встановіть кореневий ЦС у довірених сховищах на ваших мережевих пристроях Просто створити корінь довіри недостатньо; вам потрібно буде розгорнути його у своїх мережах, щоб пристрої довіряли йому. Однак розгортання ваших приватних кореневих ЦС вручну є виснажливим процесом. Це передбачає перехід від одного пристрою до наступного для встановлення сертифіката в надійне сховище сертифікатів кожного пристрою за допомогою Microsoft Management Console (MMC) із оснащенням Certificates. Інакше інші пристрої в мережі не довірятимуть приватному кореневому ЦС.

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

11. Створіть API для запитів і видачі сертифікатів
Зробіть свій приватний PKI максимально зручним за допомогою інтуїтивно зрозумілого інтерфейсу прикладного програмування (API). Це інструмент, який авторизовані користувачі використовуватимуть для запиту, поновлення, відкликання або завантаження своїх цифрових сертифікатів. Але налаштування власного центру сертифікації з нуля часто означає створення спеціального API. Одним із підходів може бути використання бібліотек RESTful. Але що робити, якщо створювати цей тип нестандартного інструменту не в ваших силах? Це може спричинити багато головного болю для вас і вашої команди. Але хороша новина полягає в тому, що існують рішення сторонніх розробників, які мають вбудовані API.

12. Налаштуйте системи резервного копіювання для ваших приватних сертифікатів PKI та бази даних
Перш ніж йти далі, знайдіть час, щоб створити резервні копії ваших криптографічних ключів (через клонування, про що ми вже говорили), сертифікатів, бази даних та інших пов’язаних з PKI цифрових активів. Це те, що відновить роботу вашого бізнесу, якщо щось піде не так, що вплине на безпеку ваших цифрових сертифікатів і активів, які вони захищають. Процес створення та підтримки приватних резервних копій PKI буде відрізнятися залежно від інструментів і програмного забезпечення, які ви використовуєте для створення та керування PKI. За словами Microsoft , ви можете зробити це для Microsoft CA за допомогою оснастки центру сертифікації в AD CS.

13. Включіть свій приватний ЦС у ваші плани безперервності бізнесу та аварійного відновлення
Життя іноді кидає криві кулі, і все йде не так. Ви можете стати жертвою потужної кібератаки або статися стихійне лихо. Незалежно від того, чому трапилося щось погане, дуже важливо, щоб у вас були плани, щоб підтримувати роботу вашого бізнесу, поки ви перебуваєте в епіцентрі подій, і повернути себе до 100% після того, як ви вирішите ситуацію. Одна з найбільших помилок, яку ви можете зробити, впроваджуючи приватну PKI, це не включити її у свої плани на випадок надзвичайних ситуацій. Приватний ланцюг довіри ЦС вашої компанії є ключовим елементом для збереження ваших найбільш конфіденційних даних, незважаючи на обставини. Щоб переконатися, що вони залишаються в безпеці, вам потрібно включити ваш приватний PKI в ці панелі.

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

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

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

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

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

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