НОУ ІНТУІТ, Лекція, Інфраструктури відкритих ключів

6.1.8 Перехресна сертифікація Notes

Domino використовує два типи перехресних сертифікатів: перехресні сертифікати Notes та перехресні інтернет-сертифікати. Перехресні сертифікати Notes ми опишемо у цьому розділі, а перехресні інтернет-сертифікати – у розділі про інфраструктуру відкритих ключів в Інтернеті далі у цій лекції.

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

Що таке сертифікати Notes?

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

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

У зв'язку з цим регулярно постає питання: "Як ми можемо поєднати кілька ієрархій сертифікації чи дерев імен?" Відповідь полягає в тому, що, хоч і неможливо просто і ефективно поєднати кілька існуючих дерев сертифікації в одну-єдину ієрархію сертифікації, можливість досягти успіху в цьому напрямі існує.

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

Це досягається за допомогою перехресної сертифікації, яка є формою однорангової довірчої моделі (сертифікації).

Три типи перехресної сертифікації

Перехресна сертифікація може зустрічатися в організації різних рівнях. Існує три можливі типи перехресної сертифікації, як це представлено далі:

між двома організаціями (чи підрозділами організацій);
між двома користувачами чи серверами;
між організацією та користувачем чи сервером.

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

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

Перехресна сертифікація між двома організаціями

Припустімо, що відбувся типовий для наших днів випадок з життя організацій, при якому дві окремі організації, Widget і Acme, вирішили об'єднатися.

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

Для досягнення цієї мети буде виконано такі кроки:

Джерело сертифікації організації Acme ( /Acme ) отримує перехресний сертифікат для джерела сертифікації організації Widget ( /Widget ) та зберігає його в каталозі Domino організації Acme.
Джерело сертифікації організації Widget ( / Widget ) отримує перехресний сертифікат для джерела сертифікації організації Acme ( / Acme ) і зберігає його в каталозі Domino організації Widget.

Як результат цієї процедури встановлюються спеціальні відносини (кажуть: "Acme та Widget довіряють один одному"). Це явище показано на рис. 6.10. У цій моделі перехресної сертифікації всі користувачі та сервери обох організацій можуть тепер проводити аутентифікацію один одного.

Перехресна сертифікація між двома користувачами

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

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

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

Будуть виконані такі кроки:

Як результат цієї процедури встановлюються спеціальні відносини (кажуть: "Сервер Acme та сервер Widget довіряють один одному"). Це явище показано на рис. 6.11. У цій моделі перехресної сертифікації лише ці два сервери довіряють один одному і можуть здійснювати реплікацію один з одним.

Перехресна сертифікація між організацією та користувачем

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

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

Тут одна з організацій бажає провести найбільш обмежену форму перехресної сертифікації, а іншу організацію влаштовує найбільш ліберальна форма перехресної сертифікації, коли один сервер організації Acmeпроводить аутентифікацію та реплікацію з будь-яким сервером організації Widget.

Будуть виконані такі кроки:

Як результат цієї процедури встановлюються спеціальні відносини (кажуть: "Сервер Acme та організація Widget довіряють один одному"). Це явище показано на рис. 6.12. У цій моделі перехресної сертифікації серверу Acme довіряє вся організація Widget, і відповідно цей сервер Acme може виконувати реплікацію з будь-яким сервером організації Widget.

Процедура перехресної сертифікації

Щоб отримати додаткову інформацію про перехресну сертифікацію та реальні етапи її виконання, зверніться до документації на програмний продукт Domino 6 або до файлу допомоги адміністратора Lotus Domino 6.

6.1.9 Аутентифікація

Аутентифікація є найважливішим аспектом забезпечення безпеки. Вона важливіша, ніж шифрування. Ми торкалися цієї теми в "Основи ІТ-безпеки", а тепер настав момент повторно звернутися до цього поняття.

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

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

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

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

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

Аутентифікація є елементом, який дозволяє адміністраторам дозволяти чи забороняти доступ до ресурсів системи. Якщо особа отримала дозвіл на доступ до системи, то цій особі можуть бути надані різні привілеї (зазвичай звані рівнями доступу).

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

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

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

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