- •1. Основні характеристики grid-технологій 6
- •2. Методи безпеки в grid – технологіях 30
- •3. Інфраструктура захисту Grid (gsi) 33
- •3.2.2. Аутентифікація 52
- •3.2.3. Авторизація 53
- •4. Засоби безпеки grid - технологій 63
- •5. Перелік робіт по створенню комплексної системи захисту інформації в Українському Грід 75 вступ
- •Основні характеристики grid-технологій
- •1.1. Напрями розвитку технології Grid
- •1.2. Концепція побудови grid
- •1.3. Стандартизація Grid
- •Архітектура Grid
- •1.4.1. Базовий рівень
- •1.4.2. Рівень зв'язку
- •1.4.3. Ресурсний рівень
- •1.4.4. Колективний рівень
- •1.4.5. Прикладний рівень
- •1.4.6. Стандарти, що використовуються для побудови архітектури grid
- •1.4.6.1. Сервіс-орієнтована архітектура
- •1.4.6.2. Мова описів Web - сервісів
- •1.4.6.5. Протокол soap (Simple Object Access Protocol)
- •2. Методи безпеки в grid – технологіях
- •2.1. Основні положення
- •2.2. Вимоги безпеки
- •2.2.1. Множинні інфраструктури безпеки
- •3.1.1. Безпечна комунікація
- •3.1.1.1. Три ключові елементи безпечної комунікації
- •3.1.1.2. Конфіденційність
- •3.1.1.4. Аутентифікація
- •3.1.2. Авторизація
- •3.1.3. Авторизація порівняно з Аутентифікацією
- •3.1.4. Введення в криптографію
- •3.1.4.1. Алгоритми засновані на ключі
- •3.1.4.2. Симетричні і асиметричні алгоритми, засновані на ключі
- •3.1.4.3. Криптографія загального ключа
- •3.1.4.4. Безпечний діалог, з використанням криптографії загального ключа
- •3.1.4.5. Переваги і недоліки систем, заснованих на загальному ключі
- •3.1.5. Цифрові підписи: Цілісність в системах з відкритим ключем
- •3.1.6. Аутентифікація в системах із загальним ключем
- •3.1.7. Сертифікати і центри сертифікації (ca)
- •3.1.9. Формат сертифікату X.509
- •3.1.10. Видатні імена
- •3.1.11. Ієрархії ca
- •3.2. Введення в gsi
- •3.2.1. Захист транспортного рівня і рівня повідомлень
- •3.2.2. Аутентифікація
- •3.2.3. Авторизація
- •3.2.3.1. Авторизація серверної сторони
- •3.2.3.2. Авторизація клієнтської сторони
- •3.2.3.3. “Custom” авторизація
- •3.2.4. Делегація і єдиний вхід (проксі-сертифікати)
- •3.2.5.1. Рішення: проксі-сертифікати
- •3.2.5.2. Що досягає рішення: Делегація і єдиний вхід
- •3.2.5.3. Особливість
- •3.2.5.4. Створення проксі-сертифіката
- •3.2.5.5. Підтвердження проксі-сертифіката
- •3.2.5.6. Додатково про проксі-сертификати
- •3.2.5.7. Контейнер, служба, і захист ресурсу
- •4. Засоби безпеки grid - технологій
- •4.1. Сучасний стан програмного забезпечення інфраструктури grid
- •4.2. Програмне вирішення globus
- •4.3. Система Gridge
- •4.4. Програмне забезпечення lcg
- •Перелік робіт по створенню комплексної системи захисту інформації в Українському Грід
- •2. На стадії технічного проектування:
- •3. На стадії робочого проектування:
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.
