Інфраструктура захисту Grid (GSI)

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

3.1. Фундаментальні поняття захисту

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

• Практическая Криптография. Bruce Schneier. John Wiley & Sons, 2003.

http://www.schneier.com/book-practical.html

• Прикладная Криптография. Bruce Schneier. John Wiley & Sons, 1996.

http://www.schneier.com/book-applied.html

3.1.1. Безпечна комунікація

Фахівці в області захисту даних комп'ютера часто вважають, що “безпечна комунікація” – це просто будь-яка комунікація, де кодуються дані. Проте захист містить в собі набагато більше, ніж просто кодування і розшифровка даних.

3.1.1.1. Три ключові елементи безпечної комунікації

Більшість авторів розглядають три основні елементи безпечної комунікації (або “безпечного діалогу”): конфіденційність, цілісність, і аутентифікація. Безпечний діалог повинен представляти всі три елементи, але не завжди (іноді це, навіть не було б бажано). Різні сценарії захисту могли вимагати різні комбінації характеристик (наприклад “тільки конфіденційність”, “конфіденційність і цілісність без аутентифікації”, “тільки цілісність”, і тому подібне).

Примітка:Існують книги і URL, які також говорять про “незречення” (non-repudiation), особливість яку деякі автори розглядають як четвертий ключовий елемент безпечних діалогів. “Незречення” не описується в літературі тому, що більшість авторів прагнуть просто вважати це частиною аутентифікації і в цьому документі ця характеристика не буде розглянута.

3.1.1.2. Конфіденційність

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

Наприклад, припустимо, що потрібно передати повідомлення “INVOKE METHOD ADD”, і необхідна упевненість, що якщо третя сторона перехопить це повідомлення (наприклад, використовуючи мережевий сніфер), вона не зможуть його розібрати. Можна використовувати звичайний алгоритм кодування, який просто змінює кожну букву на наступну в алфавіті. Кодоване повідомлення було б “JOWPLFANFUIPEABEE” (припустимо, що “A” слідує після символу пропуск). Якби третя сторона знала використовуваний алгоритм кодування, повідомлення не мало б сенсу. З іншого боку одержуюча сторона знала б алгоритм розшифровки заздалегідь (змінивши кожну букву на попередню в алфавіті) і тому могла розібрати повідомлення. Звичайно, цей метод тривіальний, і в даний час алгоритми кодування набагато більш ускладнені. Деякі з таких алгоритмів будуть розглянуті нижче.

3.1.1.3. Цілісність

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

Традиційні алгоритми кодування не захищають від такого роду атак. Наприклад, розглянемо простій алгоритм, який був запропонований вище. Якщо третя сторона використовувала мережевий сніфер, щоб змінити кодоване повідомлення на “JAMJAMJAMJAMJAMJA”, одержуюча сторона використовувала б алгоритм розшифровки і отримала повідомлення “I LI LI LI LI LI “. Хоча атакуюча сторона, можливо, не мала б ніякого поняття, що повідомлення містить, але, проте, могла змінити його (відносно просто для деяких мережевих інструментів сніферів). Так легко ввести в оману одержуючу сторону, яка могла б сприйняти це як помилку в комунікації. Алгоритми криптографії загального ключа (буде коротко розглянутий далі) захищають від видів нападів (одержуюча сторона має спосіб дізнатися, якщо отримане повідомлення послане передавальною стороною і, таким чином, не було змінено).

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

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

3.1.2. Авторизація

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

Наприклад, як тільки буде з'ясовано, що користувач входить до складу Відділу Математики, потрібно буде потім дозволити йому звернутися до всіх Мат. служб. Проте, можливо, йому заборонили б звертаються до інших служб, що не пов'язані з його відділом (BiologyService, ChemistryService, і тому подібне)

3.1.3. Авторизація порівняно з Аутентифікацією

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

3.1.4. Введення в криптографію

Криптографія – “мистецтво запису в секретних символах”. Кодування – дія перекладу нормального повідомлення в повідомлення, записане з “секретними символами” (також відоме як кодоване повідомлення).

Розшифровка – дія перекладу повідомлення, записаного з “секретними символами” в читане повідомлення (розкодоване повідомлення). Криптографія, безумовно, одна з найголовніших областей в захисті даних комп'ютера, оскільки сучасні алгоритми кодування можуть гарантувати всі три елементи безпечного діалогу: конфіденційність, цілісність, і аутентифікацію.

3.1.4.1. Алгоритми засновані на ключі

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

Алгоритм заснований на ключі використовує ключ кодування, щоб кодувати повідомлення. Це означає, що кодоване повідомлення генерується, використовуючи не тільки повідомлення, але і, використовуючи “ключ” (Рис.№3)

Рисунок 3. Кодування засноване на ключі

Одержувач може потім використовувати ключ розшифровки, щоб розшифрувати повідомлення. Знову-таки, це означає, що алгоритм розшифровки залежить не тільки від кодованого повідомлення. Також буде потрібно “ключ” (Рис.№4)

Рисунок 4. Розшифровка заснована на ключі

Деякі алгоритми використовують один ключ для кодування і розшифровки, а інші різні. Про різні ключі буде розказано нижче.

Розглянемо простий приклад. Припустимо, алфавітно-цифрові символи не передаються, а передаються тільки числові символи (для простоти прикладу). Наприклад, відбувається передача наступного повідомлення:

1 2 3 4 5 6 5 4 3 2 1

Виберемо ключ, який використовуватиметься для кодування повідомлення. Імовірно ключ буде “4232”. Щоб кодувати повідомлення потрібно буде повторювати ключ, стільки скільки необхідно, для “покриття” цілого повідомлення:

1 2 3 4 5 6 5 4 3 2 1

4 2 3 2 4 2 3 2 4 2 3

Кодування повідомлення з додаванням обох номерів:

1 2 3 4 5 6 5 4 3 2 1

+ 4 2 3 2 4 2 3 2 4 2 3

-----------------------

5 4 6 6 9 8 8 6 7 4 4

Результуюче повідомлення (54669886744) – закодоване повідомлення. Повідомлення може бути розшифровано слідуючи зворотному процесу: повторюючи ключ, стільки раз скільки потрібно, щоб покрити повідомлення, а потім відняти кожен з символів ключа:

5 4 6 6 9 8 8 6 7 4 4

- 4 2 3 2 4 2 3 2 4 2 3

-----------------------

1 2 3 4 5 6 5 4 3 2 1

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

Слід зазначити, що це дуже тривіальний приклад. Поточні алгоритми, засновані на ключі, набагато складніші (ключі набагато довші, і процес кодування не такий простий, як “додавання повідомлення і ключа”). Проте ці складні алгоритми засновані на тому ж основному принципі, показаному в нашому прикладі: ключ потрібний, щоб кодувати/розшифрувати повідомлення.

3.1.4.2. Симетричні і асиметричні алгоритми, засновані на ключі

Алгоритм прикладу підпадає в категорію симетричних алгоритмів. Цей тип алгоритму використовує один ключ для кодування і розшифровки (Рис.№5).

Рисунок 5. Симетричний алгоритм, заснований на ключі

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

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

3.1.4.3. Криптографія загального ключа

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

• Приватний ключ: Цей ключ повинен знати тільки його власник.

• Загальний ключ: Цей ключ відомий кожному (він загальний).

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

3.1.4.4. Безпечний діалог, з використанням криптографії загального ключа

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

Рисунок 6. Асиметричний алгоритм заснований на ключі

3.1.4.5. Переваги і недоліки систем, заснованих на загальному ключі

Системи такого роду мають явну перевагу над симетричними алгоритмами: немає ніякої необхідності погоджувати загальний ключ, як для відправника, так і одержувача. Як видно в попередньому прикладі, якщо хто-небудь хоче отримати кодоване повідомлення, відправникові тільки потрібно знати загальний ключ одержувача (забезпечується одержувачем; видання загального ключа жодним чином не ставить під загрозу безпечну передачу). У міру того, як одержувач зберігає приватний ключ в таємниці, ніхто окрім одержувача не зможе розшифрувати повідомлення, закодоване відповідним загальним ключем. Це досягається завдяки тому, що в системах із загальним ключем, це відносно просто, щоб обчислити загальний ключ з приватного ключа, але дуже складно обчислити приватний ключ виходячи із загального ключа (який є загальновідомим). Фактично, на виконання деяких алгоритмів буде потрібно декілька місяців(і навіть років) постійних обчислень, щоб отримати приватний ключ виходячи із загального ключа. (Рис.№7)

Рисунок 7. Генерація загального ключа

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

Основний недолік використання систем з відкритим ключем в тому, що вони не так швидкі як симетричні алгоритми.

3.1.5. Цифрові підписи: Цілісність в системах з відкритим ключем

Цілісність гарантується в системах з відкритим ключем, в яких використовуються цифрові підписи. Цифровий підпис – це частина даних, яка прикріпляється до повідомлення і яка може використовуватися, щоб з'ясувати чи було замінено повідомлення протягом діалогу (наприклад, через втручання зловмисника) (Рис.№8).

Рисунок 8. Цифровий підпис

Цифровий підпис для повідомлення генерується на двох етапах:

1. Генерується Резюме повідомлення. Резюме повідомлення – короткий звіт передаваного повідомлення, має дві важливі властивості: (1) Він завжди менший, ніж повідомлення безпосередньо (2) Навіть найлегша зміна в повідомленні проводить різне резюме. Резюме повідомлення генерується з використанням безлічі алгоритмів хешування.

2. Резюме повідомлення кодується, використовуючи приватний ключ відправника. Підсумкове закодоване резюме повідомлення і є цифровий підпис.

Цифровий підпис прикріпляється до повідомлення, і відправляється одержувачеві. Одержувач потім виконує наступне:

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

2. Використовує той же алгоритм резюме повідомлення, використовуваний відправником, щоб генерувати резюме отриманого повідомлення.

3. Порівнює обидва резюме повідомлення (одне послане відправником як цифровий підпис, а інше генерується одержувачем). Якщо вони не співпадають це означає що повідомлення змінене третьою стороною. Можемо бути упевнені, що цифровий підпис послав відправник (не зловмисник) оскільки тільки загальний ключ відправника може розшифрувати цифровий підпис (який був закодований приватним ключем відправника; важливе те, що один ключ кодує, інший розшифровує, і навпаки). Якщо, розшифровка, використовуючи загальний ключ, надає помилкове резюме повідомлення, це означає, що повідомлення або резюме повідомлення не відповідають тому, що послав відправник.

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

3.1.6. Аутентифікація в системах із загальним ключем

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

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

3.1.7. Сертифікати і центри сертифікації (CA)

Цифровий сертифікат – це цифровий документ, який засвідчує, що певний загальний ключ належить конкретному користувачеві. Сертифікат підписує третя сторона іменована центр сертифікації (або CA). Мал. №9 ілюструє, що є цифровим свідоцтвом.

Рисунок 9. Цифровий сертифікат

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

Тому, можемо перевірити цілісність сертифікату, використовуючи загальний ключ CA.

3.1.8. Довіра

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

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

Потрібно буде вирішити який CA включити в цей список. Деякі CA добре відомі і їх включають за умовчанням в багатьох системах із загальним ключем (наприклад, веб-навігатори зазвичай включають VeriSign (http://www.verisign.com) і GlobalSign (http://www.globalsign.com) сертифікати, тому що багато веб-вузлів використовують сертифікати, випущені цими компаніями. Звичайно, є можливість додати і інший CA до “Довіреного списку”. Наприклад, якщо ваш відділ встановлює CA, і ви довіряєте, що CA відділ видаватиме свідоцтва тільки надійним людям, тому ви можете додати його до списку.

3.1.9. Формат сертифікату X.509

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

• Суб'єкт: Це ім'я користувача. Воно кодується як видатне ім'я (формат для різних імен буде пояснений далі)

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

• Запрошуюча сторона: видатне ім'я CA.

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

Як видно, інформація, яку можна знайти в сертифікаті X.509, - та ж, що була показана на ілюстрації (ім'я, ім'я CA, загальний ключ, підпис CA). Варто звернути увагу, що сертифікат, не включає приватний ключ, який повинен бути збережений окремо від загального ключа.

Пам'ятаєте, що сертифікат – загальний документ, який потрібно поширювати до інших користувачів, для перевірки особи, оскільки не рекомендується включати в нього приватний ключ (повинен бути відомий тільки власникові сертифікату). Сертифікат і пов'язаний з ним приватний ключ, загалом, посилаються як посвідчення особи користувача.

3.1.10. Видатні імена

Імена в сертифікатах X.509 не кодуються просто як “загальні імена”, як наприклад “Borja Sotomayor, “Lisa Childers”, “Центр сертифікації XYZ”, або “Системний Адміністратор”. Вони кодуються, як видатні імена, які є списком пар значення імені відокремленими комою. Розглянемо приклад з видатними іменами:

O=University of Chicago, OU=Department of Computer Science, CN=Borja Sotomayor

O=Argonne National Laboratory, OU=Mathematics and Computer Science Division, CN=Lisa Childers

Що означають “O”, “OU”, і “CN”? Видатне ім'я може мати декілька різних атрибутів, ось основні з них:

• O: Організація

• OU: Організаційний Підрозділ

• CN: Загальне Ім'я (загалом, ім'я користувача)

• C: Країна

3.1.11. Ієрархії CA

Раніше було згадано що “довірений список” CA включає сертифікати всіх довірених CA. Тому, виникає питання: І хто підписує сертифікат CA? Відповідь дуже проста: Інший CA. В результаті це дозволяє щоб ієрархія CA створювалася, таким чином, що хоча, можливо, не довіряєте CA (оскільки він не знаходиться в довіреному списку), можливо, довірили б CA вищого рівня, який підписав його сертифікат (який робить нижчестоячий CA надійним). Рис.№10 відображає ланцюг перевірки сертифікату:

Рисунок 10. Ланцюг перевірки сертифікату

На малюнку сертифікат Borja підписує центр сертифікації FOO. Сертифікат центру сертифікації FOO, у свою чергу, підписується центром сертифікації BAR. Нарешті, сертифікат BAR підписує сам себе.

Якщо ви отримуєте сертифікат Borja, і явно не довіряєте CA FOO (запрошуюча сторона сертифікату), це не означає, що сертифікат не надійний. Ви, можливо, перевірили б, що сертифікат CA FOO випустив CA, якому ви довіряєте. Якщо з'ясується що CA BAR знаходиться у вашому “довіреному списку”, це означатиме, що свідоцтво Borja надійно.

Проте зверніть увагу, що CA (BAR) вищого рівня підписав свій власний сертифікат. Це цілком нормально, і називається само-підписаним сертифікатом. CA з само-підписаним сертифікатом називається кореневий CA, тому що немає нікого вище. Щоб довірити сертифікату, підписаному цим CA, він повинен обов'язково бути у вашому “довіреному списку” CA.