Встановлюємо certification authority (частина 1)

Посилання на інші матеріали з цієї серії:

• Встановлюємо Certification Authority - Підведення підсумків

По-перше, потрібно визначитися з завданнями, які можуть зажадати запровадження PKI:

Якщо з усього перерахованого вище вам не потрібно, PKI вам не потрібна так само.

В одному зі своїх попередніх постів я вів дискусію про ієрархіях PKI: Обговорення схем ієрархії Certification Authority. На основі цього матеріалу ми подбеёрм схему для нашої інсталяції, яка буде описана в даному матеріалі. Виходячи з написаного за посиланням ми відразу відкидаємо варіант однорівневої ієрархії. Дворівнева ієрархія виглядає дуже привабливо:

В принципі, якщо мережа досить сконцентрована, така схема буде ідеальною для багатьох випадків. А якщо мережа географічно розподілена з великими філіями (сайтами), в кожен такий філія можна додати по ще одному сертифікату CA і отримати ось таку схему:

Створення 3-х рівневої ієрархії вже буде мати на увазі поділ іерерхіі на області дій CPS (Certificate Practice Statement) і будуть схильні до різних політиків управління серверами CA. Це досить довга пісня і про неї говорити не будемо. Тому ми зупинимося на дворівневої ієрархії з одним кореневим центром сертифікації (Root CA) і одним видає центром сертифікації (Issuing CA).

Microsoft підтримує два типи центрів сертифікації - Standalone і Enterprise. Зазвичай адміністратори звикли встановлювати Enterprise CA і з очевидних причин не використовують Standalone CA. Чим вони відрізняються?

За своїми можливостями Standalone CA виглядає убогим трохи більше, ніж повністю. Але цей тип CA має одне суттєва перевага - він не залежить від наявності домену. Здається - фігня. Домени навіть рулять і педаль і все, що працює без домену не потрібно! Але давайте подивимося на ситуацію трохи з іншого боку. Центри сертифікації верхніх рівнів (кореневі і підлеглі центри сертифікації першого рівня) мають як правило дуже великий термін дії - від 10 до 20 років. При цьому дуже часто домени і ліси AD живуть значно менше, оскільки вони постійно реструктуірутся, перейменовуються, мігрують і т.д. А центр сертифікації в домені (Enteprprise CA) позбавляє нас деяких можливостей, як перейменування домену та ускладнюють процеси реструктуризації доменів і лісів. З цієї причини, Enterprise CA має невеликий термін дії своїх сертифікатів - від 5 до 10 років максимум. В принципі, якщо є незалежний від домену AD центр сертифікації (Standalone CA в робочій групі) набагато простіше проводити міграцію і реструрізацію лісів AD, оскільки ці процеси не зачіпають кореневої CA і позбавляють від проблем побудови нової ієрархії PKI. У такій ситуації досить тільки змінити центри сертифікації 2-го і 3-го рівнів (останній зазвичай є Enterprise CA). Саме з цієї причини кореневі центри сертифікацій доцільно встановлювати поза домену, в робочій групі.

Центр сертифікації рівня підприємства (як це випливає з назви) абсолютно не схожий на Standalone CA за своїми можливостями. По-перше Enterprise CA вимагає наявності домену для зберігання там своєї інформації і шаблонів сертифікатів. Даний тип CA має дуже великі можливості з видачі та обслуговування сертифікатів. Enterprise CA не вимагає генерації файлів запитів з боку клієнтів, а дозволяє подавати заявки на сертифікати через оснащення Certificates консолі MMC і автоматично поширювати сертифікати в масштабах цілого лісу AD за мінімальної участі кінцевого користувача. Найчастіше це участь зводиться до налаштування адміністратором політик autoenrollment'а і все. Плюс, Enterprise CA може публікувати сертифікати в якості облікових записів користувачів і комп'ютерів.

Однак, залежність від домену вносить деякі обмеження в своє життя. Оскільки домени досить рухомі одиниці і схильні до змін, Enterprise CA мають досить короткий термін дії своїх сертифікатів - від 5 до 10 років максимум. У разі Enterprise Root CA, видалення домену автоматично веде до краху всієї ієрархії PKI і її доведеться будувати з нуля, що може вилитися у великі труднощі в доважок до поточних проблем видалення домену. Саме тому компанії ніколи не встановлюють кореневої центр сертифікації на Enterprise CA, а тільки Issuing CA, які вже видають сертифікати кінцевим споживачам, де і восстребован всі можливості Enterprise CA. Хоча, в дуже невеликих компаніях цього буде цілком достатньо, коли кореневої CA встановлюється на Enterprise CA і має термін дії сертифіката 5 років.

В даному циклі статей ми будемо використовувати переваги обох типів CA. Для кореневого CA будемо використовувати Standalone CA в робочій групі і для видає CA будемо використовувати Enterprise CA в домені Active Directory. При цьому Standalone CA не видаватиме сертифікати кінцевим споживачам, а тільки для інших центрів сертифікації.

На який термін будемо видавати сертифікати для кожного типу CA? 20 років мені здається занадто круто, адже через 20 років у вашій компанії може все круто змінитися і якщо ваш бізнес не зав'язаний на надання послуг цифрових сертифікатів, 20 років, напевно, занадто великий термін. А ось 10 років для кореневого і видає буде цілком достатньо. Не треба думати, що через 10 років все помре. Просто через 10 років (фактично трохи раніше, через 8-9 років) вам доведеться оновити сертифікати обох CA і все, життя триватиме далі. Витрати на оновлення сертифікатів CA мінімальні, оскільки ніяких змін в конфігурації проводити не доведеться.

Про це у мене написано вже досить багато:

Так само можна передбачити використання OCSP (Online Certificate Status Protocol). Хоч зазвичай OCSP і використовується тільки для Enterprise CA, нічого не заважає використовувати його для кореневого CA. З урахуванням зростання кількості клієнтів під управлінням Windows Vista і вище, це буде хороший експеріенс і я розповім, як це можна буде реалізувати.

Виходячи з вищесказаного ми можемо сформулювати програмні вимоги для нашої ієрархії PKI:

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