Приклади 1) проміжного ЗЦ у відкритій ієрархії довіри і 2) приватної ієрархії, яка ізольована від відкритої ієрархії, зі своїм власним кореневим ЗЦ
Інфраструктура відкритих ключів (PKI) традиційно має ієрархічну структуру. У ній засвідчують центри (ЗЦ) пов’язані відносинами підпорядкованості. Всі користувачі довіряють одному і тому ж кореневому (головному) ЗЦ, а кожен нижчий ЗЦ підпорядковується вищому в ієрархії.
Але що, якщо треба створити приватну інфраструктуру PKI зі своїм власним ЗЦ? Дійсно, в деяких ситуаціях такі проміжні або приватні ієрархії дуже зручні на практиці.
Типові причини для створення проміжної або приватної ієрархії
- Аутентифікація клієнтів
Аутентифікацію клієнтів за сертифікатами зручно зробити на основі проміжного ЗЦ. При наявності ексклюзивного підлеглого ЗЦ можна обмежити число сертифікатів, що надають доступ до системи. У цих випадках зазвичай використовуються приватні ієрархії довіри.
- Брендинг
Для компаній, які пропонують сертифікати своїм клієнтам або включають їх в комплект послуг, що надаються, наявність свого виділеного ЗЦ дозволяє запропонувати деякі додаткові можливості брендингу.
- Інспекція/дешифрування SSL/TLS
Щоб пристрій перевірки SSL міг дешифрувати і заново шифрувати контент, у нього повинна бути можливість видавати сертифікати в міру необхідності. Це означає, що потрібен власний підлеглий ЗЦ поза суспільної ієрархії довіри. В цьому випадку кореневий ЗЦ розміщується у GlobalSign, а проміжний ЗЦ – на пристрої перевірки сертифікатів у клієнта.
- Сертифікати спеціального призначення
Сертифікати, видані в рамках приватних ієрархій, можуть підтримувати застарілі програми та унікальні конфігурації, такі як більш тривалі періоди дії та менші розміри ключів, які не дозволені в загальнодоступних довірених сертифікатах за базовими вимогами CA/Browser Forum. Втім, якщо потрібні тільки приватні сертифікати SSL/TLS, без повноцінного власного ЗЦ, то можна скористатися послугою IntranetSSL.
- Налаштовувані профілі
Ви можете налаштувати підлеглий ЗЦ на конкретні завдання, змінивши під свої потреби політики розширеного використання ключів, політики сертифікатів, точки розповсюдження списку відкликаних сертифікатів (CRL), зробивши короткострокові сертифікати та ін.
Розміщення і підтримка
Хостинг і супровід власного ЗЦ компанія може здійснювати самостійно або віддати на аутсорсинг. Багато компаній беруться за розгортання великомасштабних систем PKI своїми силами (інсорсинг), не маючи необхідних ресурсів на це. Оскільки процес вимагає капіталовкладень, то краще заздалегідь оцінити свої матеріальні ресурси і фінансові можливості на даний момент і в найближчі роки, економічний ефект від використання нової технології, початкових витрат і вартості функціонування системи.
Провівши таку оцінку, деякі організації взагалі можуть прийти до висновку, що інфраструктура відкритих ключів їм не потрібна, а в їхньому випадку краще застосувати інший інструментарій безпеки: наприклад, VPN або програми шифрування файлів. Замість всієї інфраструктури PKI іноді простіше запустити тільки сервер сертифікатів, який вирішує проблеми несанкціонованого доступу до веб-контенту (IntranetSSL, див. вище).
Проміжна або приватна ієрархія
У відкритій ієрархії усі ЗЦ підкоряються кореневому ЗЦ, відкритий ключ якого вбудований в загальнодоступний додаток, наприклад, веб-браузер. В цьому випадку браузер може автоматично перевіряти валідність сертифікатів, виданих усіма ЗЦ у всій ієрархії, а також їх видавців, що є безперечною перевагою.
Відкриті ієрархії зазвичай використовуються в тих випадках, коли потрібен обмін інформацією з неафілійованими сторонами або їх аутентифікація. Третьою довіреною стороною в даному випадку виступає аутсорсинговий ЗЦ.
У разі приватної ієрархії кінцевий користувач вручну додає відкритий ключ корпоративного кореневого ЗЦ в список довірених ключів, вбудованих в додаток. У цьому випадку вся відповідальність за використання ключа лягає на самого користувача. Приватні ієрархії більше підходять для закритих спільнот, наприклад, користувачів корпоративного порталу.
Типові приклади проміжної або приватної ієрархії
- Виділений приватний кореневий ЗЦ і ієрархія (Private PKI)
GlobalSign може створювати і розміщувати приватні ієрархії, включаючи кореневі і проміжні. Вони побудовані на тій же захищеній інфраструктурі, яка використовується для підтримки власних кореневих ЗЦ у відкритій ієрархії.
- Фірмовий приватний проміжний ЗЦ, центр видачі сертифікатів
Брендові проміжні ЗЦ створюються спеціально для конкретного клієнта, з ланцюжком довіри до кореневого ЗЦ у відкритій ієрархії. Ці проміжні вузли теж можуть розміщуватися і підтримуватися GlobalSign, що полегшує тягар управління PKI і експертних знань для внутрішніх команд.
- Загальний відкритий кореневий ЗЦ (платформа Managed PKI)
Хоча в певних ситуаціях потрібні виділені кореневі ЗЦ і ієрархії, більшість організацій може виконати нормативні вимоги до сертифікатів за допомогою спеціалізованих сервісів на платформі управління PKI (Managed PKI). Портал для управління сертифікатами «все в одному» забезпечує розширені можливості виставлення рахунків, управління користувачами, звітність і т. д.
- Загальний приватний кореневий ЗЦ (IntranetSSL)
Рішення IntranetSSL, доступне через платформу управління PKI, дозволяє в економний спосіб видачі та управління сертифікатами SSL/TLS для внутрішніх серверів і додатків. Ці сертифікати видаються від загального, непублічного Центру сертифікації GlobalSign, тому можуть включати конфігурації, які форум CA/Browser забороняє використовувати в публічних сертифікатах (наприклад, термін дії більше трьох років, внутрішні імена серверів або зарезервовані IP-адреси).
- Корінь довіри IoT
Корені довіри IoT володіють тією ж гнучкістю, що і традиційні корені довіри, але налаштовані на специфічні вимоги IoT. Виділені приватні ієрархії, фірмові загальнодоступні проміжні ЗЦ, кореневі центри у відкритій чи приватній ієрархії можуть використовуватися для захисту пристроїв, платформ, шлюзів і мереж IoT в залежності від необхідного рівня довіри.
- Особлива ієрархія довіри
GlobalSign підтримує практично будь-яку конфігурацію ієрархії. Якщо потрібна модель, відмінна від описаної вище, або відразу не зовсім зрозуміло, яка архітектура найкраще підходить для специфічної екосистеми, то це краще обговорити з фахівцем і консультантом, щоб побудувати архітектуру довіри, яка відповідає конкретним потребам.
Для будь-якого з наведених прикладів супровід ЗЦ можна віддати на аутсорсинг. Зберігається можливість брендування, але ієрархії розміщуються і управляються GlobalSign в безпечних центрах обробки даних з перевіреним обладнанням і програмним забезпеченням. З нестандартними сценаріями допоможуть впоратися інженери супроводу.
Здається, що віддаючи свою ієрархію довіри на аутсорсинг, ви знижуєте рівень безпеки, але на практиці виходить навпаки. Це гарантує, що всі компоненти ЗЦ належним чином захищені і налаштовані у відповідності з останніми передовими галузевими практиками. Додаткова перевага – економія витрат і ресурсного навантаження на внутрішні команди для підтримки PKI. Тільки в деяких рідкісних випадках (наприклад, перевірка/дешифрування SSL) проміжна ланка повинна розміщуватись у клієнта.
Джерело: habr.com
