Введення в GSI

Інфраструктура Grid є основою для рівня захисту GT4. Захист – одна з найголовніших частин додатку Grid. Оскільки grid має на увазі перетин меж організації, ресурси стають доступними для інших організацій. Це формулює багато вимог:

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

Наприклад, організація AliceOrg просить BobOrg виконати певне завдання. BobOrg, з іншого боку, усвідомлює, що завдання потрібно делегувати до організації CharlieOrg. Проте можна вважати, що CharlieOrg довіряє тільки AliceOrg (але не BobOrg). Чи повинен CharlieOrg відкинути запит, тому що він виходить від BobOrg, або приймати його, оскільки початковий прохач AliceOrg?

Залежно від додатку, можливо, також є зацікавленість в цілісності даних і конфіденційності, хоча в grid- застосуванні це, загалом, не так важливо як аутентифікація.

Інструментарій Globus 4 дозволяє долати проблеми захисту, сформульовані grid-додатками через Інфраструктуру Захисту Grid (або GSI). GSI складається з набору інструментів командного рядка для управління сертифікатами, і безліччю класів Java для легкого об'єднання захисту у веб-службах. GSI пропонує програмістам наступні характеристики:

· Захист транспортного рівня і рівня повідомлень;

· Аутентифікація через цифрові сертифікати X.509;

· Різні схеми авторизації;

· Делегація посвідчення особи і єдиний вхід (sign-on);

· Різні рівні захисту: контейнер, обслуговування, і ресурс

3.2.1. Захист транспортного рівня і рівня повідомлень

Транспортний рівень використовує TLS – Transport Layer Security (SSL – Secure Sockets Layer). Рівень повідомлень має дві реалізації, засновані на різних стандартах: WSSecurity і WS-SecureConversation. При встановленні з'єднання по WS-SecureConversation визначається, так званий, контекст безпеки (secure context). Після ініціалізації обміну повідомленнями всі подальші повідомлення використовують цей контекст безпеки. Крім того, на відміну від WS-Security, WS-SecureConversation забезпечує анонімну аутентифікацію і делегування має рацію.

GSI дозволяє розвернути захист на двох рівнях: транспортний рівень або рівень повідомлень. Відмінності між цими рівнями: припустимо необхідно, щоб комунікація була приватною. Якщо використовується захист транспортного рівня, як показано на мал. №11, у такому разі всі комунікації (вся інформація між клієнтом і сервером) кодувалася б. Якщо використовується захист для рівня повідомлень, як показано на рис.№12, в цьому випадку кодується тільки вміст повідомлення SOAP, а решта частини повідомлення SOAP не кодується.

Рисунок 11. Захист транспортного рівня

Рисунок 12. Захист рівня повідомлень

Як транспортний рівень, так і захист рівня повідомлень в GSI засновані на криптографії “відкритого ключа” (public-key) і, тому, може гарантувати конфіденційність, цілісність, і аутентифікацію. Проте не всім зв'язкам буде потрібно всі три характеристики. Взагалі, безпечний діалог GSI повинен як мінімум бути засвідчений. Цілісність бажана зазвичай, але може бути відключена. Кодування також може бути активізоване, щоб гарантувати конфіденційність.

Порівняння роботи рівня повідомлень і транспортного рівня: транспортний рівень захисту використовується вже тривалий час і, трапляється, що він використовується навіть при звичайному перегляді Веб, з тих пір, як безпечні веб-вузли почали покладатися на захист транспортного рівня. Захист рівня повідомлень у веб-службах відносно новий і, хоча він має в своєму розпорядженні більші характеристики, чим захист транспортного рівня (наприклад, краща інтеграція із стандартами веб-служб), його робота все ще не досягла необхідного рівня. Таким чином, хоча і передбачається використовувати захист рівня повідомлень (із-за безлічі якісних характеристик), іноді доводиться розглядати використання захисту транспортного рівня, якщо потрібний добрий результат. Звідси ясно, які переваги у транспортного рівня: продуктивність і простота реалізації, унаслідок того, що не треба проводити розбір шифрованих повідомлень на складові. Рівень повідомлень, з іншого боку, надає більше можливостей, наприклад, має рацію делегування . Фактично, захист транспортного рівня використовується за умовчанням в інструментарії Globus. Великим плюсом реалізації системи безпеки в Globus Toolkit є те, що вона дозволяє комбінувати можливості цих рівнів безпеки один з одним в різних варіантах, дозволяючи тим самим підібрати оптимальний варіант для кожного конкретного завдання.

GSI пропонує дві схеми захисту рівня повідомлень, і одна схема для транспортного. Відмінності між ними представлені в таблиці.№3.

Безпечне Повідомлення GSI: Забезпечує захист рівня повідомлень і засновано на запропонованому стандарті WS-Security.

Безпечний Діалог GSI: Забезпечує захист рівня повідомлень і заснований на специфікації WS-SecureConversation. Якщо вибраний цей метод, встановлюється контекст безпеки (secure context)між клієнтом і сервером. Після початкового обміну повідомленнями, щоб встановити контекст, всі наступні повідомлення зможуть використовувати цей контекст багато разів, що приводить до кращої роботи, чим Безпечне Повідомлення GSI (якщо верх установки контексту прийнятний). До того ж, Безпечний Діалог GSI – це схема, яка підтримує тільки делегацію посвідчення особи.

• Транспорт GSI: Забезпечує захист транспортного рівня, використовуючи TLS – захист транспортного рівня (раніше відомий як SSL) і забезпечує кращу роботувикористовується за умовчанням в GT4. TLS і SSL – спеціальні протоколи для створення захищеного каналу між двома сторонами, що зв'язуються, що забезпечують постійне шифрування передаваної інформації і, якщо потрібно, аутентифікацію протягом одного сеансу.

Ці схеми не взаємовиключні. Наприклад, передбачається використовувати Безпечний Діалог GSI, тому що додаток вимагає делегації, а потім додається Транспорт GSI тому що потрібно кодувати всю комунікацію (не тільки частину повідомлення SOAP). Важливо відзначити, що це не приводить до надмірності, оскільки можна конфігурувати Транспорт GSI для використання кодування і Безпечний Діалог GSI (без кодування).

Таблица 3. Порівняння захисту транспортного рівня і рівня повідомлень

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

Для вирішення аутентифікації і авторизації, необхідна наявність в системі центрів сертифікації (CA), а для крупних, територіально розподілених систем також і центру реєстрації (або інституту реєстраторів). Завдання CA – перевірити приналежність сертифікату даному індивідуумові. Кожен сертифікаційний центр проводить свою політику, яка визначає правила створення і підписання сертифікатів. GSI підтримує три аутентифікаційні методи:

Сертифікати X.509:Всі три схеми захисту, що вище перераховані, можуть використовуватися разом з сертифікатом X.509, щоб забезпечити покращувану аутентифікацію.

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

Анонімна аутентифікація: Можна запитати, щоб комунікація була анонімною, або не засвідченою. Анонімність, загалом, має сенс, коли використовується більш ніж одна схема захисту. Наприклад, можна використовувати Безпечний Діалог GSI (засвідчено з сертифікатами X.509) і анонімний Транспорт GSI, так щоб не виконувати додаткову (надмірну) аутентифікацію.

Примітка:Оскільки не засвідчені зв'язки зазвичай не використовуються, література Globus, загалом, використовує термін методи аутентифікації, щоб послатися безпосередньо на Безпечний Діалог GSI, Безпечне Повідомлення GSI, і Транспорт GSI.

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

Хоча авторизація не є одним з “Фундаментальних стовпів” безпечного діалогу, вона, проте, складає важливу частину GSI. Авторизація відзначає, хто уповноважений виконувати певне завдання. У контексті веб-служб украй важливо знати, хто уповноважений використовувати визначену веб-службу.

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

3.2.3.1. Авторизація серверної сторони

Сервер має шість можливих режимів авторизації. Залежно від вибраного режиму авторизації, сервер вирішує прийняти або відхилити вхідний запит.

None: Це найпростіший вид авторизації. В цьому випадку авторизація не виконуватиметься.

Self: Клієнтові дозволяється скористатися службою, якщо є тотожність клієнта і послуги.

Gridmap: “Gridmap” – список “зареєстрованих користувачів” який схожий з ACL (Список Контролю Доступу). При використанні цього виду авторизації, тільки перераховані в “gridmap” користувачі можуть її викликати.

Identity authorization: Клієнт може звернутися до обслуговування, якщо особа клієнта відповідає вказаній особі. Це подібно до наявності однокористувацьког “gridmap”, за винятком авторизації особи, яка конфігурується програмно, оскільки “gridmap” представлений як файл в системі.

Host authorization: Клієнт може звернутися до обслуговування, якщо він представляє посвідчення особи хоста, яке відповідає вказаному імені хоста. Іншими словами, вирішуються запити, що прибувають від одного конкретного вузла.

SAML Callout authorization: Можна делегувати вирішення авторизації до OGSA (сумісна служба авторизації). OGSA-Authz (http://forge.gridforum.org/projects/ogsa-authz) – робоча група GGF, чия мета – конкретизувати стандартні компоненти авторизації. Одна з основних технологій, використовуваних в цих компонентах, – SAML (Мова Затвердження Підвищення Захисту).

3.2.3.2. Авторизація клієнтської сторони

Авторизація клієнтської сторони дозволяє клієнтові з'ясовувати, коли можна буде викликати службу. Може здатися, що це не коректний вид авторизації, оскільки авторизація, загалом, є видимою з сервера. Режими авторизації клієнтської сторони:

None: Авторизація не виконуватиметься.

Self: Клієнт авторизує виклик, якщо особа служби співпадає з особою клієнта.

Identity authorization: Як викладено вище, клієнт тільки допустить відправку запитів до служб вказаній ідентичності.

Host: Клієнт авторизує виклик, якщо служба має посвідчення особи хоста. До того ж, клієнт повинен бути здатний вирішити адресу вузла до імені хоста, вказаного в посвідченні особи вузла.

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

3.2.3.3. “Custom” авторизація

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

3.2.4. Делегація і єдиний вхід (проксі-сертифікати)

Для вирішення єдиного входу пропонується використовувати механізм генерації проксі-сертифікатів. Від процедури видачі сертифікату центром сертифікації, даний алгоритм відрізняється тим, що роль CA тут грає користувач (точніше його клієнтська програма), а сам сертифікат видається на вельми короткий проміжок часу (звичайно не більше 12-ти годин). Крім єдиного входу в систему механізм проксі-сертифікатів також дозволяє делегувати свої права, тобто дозволяє ресурсам системи (наприклад, веб-сервисам) виконувати різні завдання від імені клієнта і з його правами доступу. Розглянемо приклад показаний на рис. №11:

Рисунок 11. Сценарій, де необхідна делегація

AliceOrg просить BobOrg виконати завдання. Оскільки BobOrg довіряє AliceOrg вона погоджується виконати завдання. Припустимо, що завдання Z дуже складне, і що одну з його підзадач (Y) повинна виконати третя організація: CharlieOrg. В даному випадку, BobOrg запитає CharlieOrg виконати subtask Y, але запит не буде виконаний, оскільки CharlieOrg довіряє тільки AliceOrg. CharlieOrg може виконати дві дії:

· Відкинути запит BobOrg. CharlieOrg не довіряє BobOrg, от і все.

· Прийняти запит BobOrg. Справжня запрошуюча сторона AliceOrg, хоча CharlieOrg відповідає на запит від BobOrg, вона фактично здійснюватиме завдання для AliceOrg.

У цій ситуації логічно буде, якщо CharlieOrg прийме запит BobOrg. Проте CharlieOrg повинна знати, що запит BobOrg виконується від імені AliceOrg, як показано на рис.№12.

Рисунок 12. Делегація

Звичайно, це не найбезпечніше рішення, оскільки хто-небудь міг запитати діяти на користь AliceOrg. Можливим рішенням може бути для CharlieOrg контактувати з AliceOrg кожного разу, коли вона отримує запит від імені AliceOrg. Проте в цьому випадку можуть виникнути деякі проблеми. Уявимо, що завдання Z складене з 20 різних підзадач, і що кожна підзадача відіслана до іншої організації BobOrg. AliceOrg буде переповнена повідомленнями, що повідомляють, що “BobOrg тільки що запитав виконати завдання від вашого імені... можете ви підтвердити, що це так?” У відповідь, AliceOrg довелося б засвідчити себе зі всіма тими організаціями і надати підтвердження.

Успішніше рішення могло так чи інакше змусити CharlieOrg вважати, що BobOrg – AliceOrg. Іншими словами, потрібно буде знайти законний шлях для BobOrg продемонструвати, що вона фактично, діє на користь AliceOrg. Одним із способів виконання цього може бути надання AliceOrg пари з відкритого і приватного ключів для BobOrg. Проте, це за межами даного питання. Важливо пам'ятати, що приватний ключ повинен зберігатися в таємниці, і відправляючи його іншій організації (не має значення наскільки їй довіряють) – це велике порушення в захисті. Для вирішення цієї проблеми буде потрібний спеціальний вид сертифікату, показаний на рис.№13.

Рисунок 13. Проксі-сертифікат

3.2.5.1. Рішення: проксі-сертифікати

Сертифікат, показаний на рис.№5 називається проксі-сертифікатом. Словник Вебстера визначає проксі як “інструмент, яким уповноважена персона виконує справи іншого”. Як видно на зображенні, проксі-сертифікат дозволяє утримувачеві сертифікату діяти на користь іншого. Фактично, це подібно цифровим сертифікатам X.509, за винятком того, що вони не підписуються Центром Сертифікації (Certificate Authority); а підписується кінцевим користувачем. Дізнатися достовірність сертифікату можна, перевіривши його підпис (Організація А підписує сертифікат в цифровій формі).

Як бути із загальним ключем проксі-сертифіката, чий цей загальний ключ, організація A, організація B? Проксі-сертіфікат має пару відкритих ключів, що згенерували спеціально для проксі-сертификата. Ця пара відкритих ключів узгоджується взаємно з обома частинами (в даному випадку, А і B), і Організація А допустить діяти в її інтересах (в даному випадку B) тільки утримувача цієї пари приватних ключів.

На розглянутому зображенні є одна упущена деталь. Дозволяти кому-небудь діяти у ваших інтересах – ризикована справа. Можливо, їм довіряють зараз для виконання конкретного завдання, але хто-небудь з Організації B, можливо, скористається проксі-сертифікатом в майбутньому, щоб здійснити несанкціоновані дії від вашого імені. Тому, тривалість життя сертифікату зазвичай дуже обмежена (наприклад, до 12 годин). Це означає що, якщо проксі-сертифікат поставлений під загрозу, нападаючий не зможе довго їм користуватися. До того ж, проксі-сертифікати розширюють звичайні сертифікати X.509 додаючи їм додаткові надбудови безпеки, щоб більше обмежити їх функціональність (наприклад, визначаючи, що проксі-сертифікат може використовуватися тільки для певних завдань). Підводячи підсумки, розглянемо більш правильне представлення проксі-сертифіката на рис.№14.

Рисунок 14. Проксі-сертіфікат з обмеженою тривалістю життя

3.2.5.2. Що досягає рішення: Делегація і єдиний вхід

Проксі-сертіфікат дозволяє користувачеві діяти на користь іншого користувача. Більш точніше це називається делегація посвідчення особи, оскільки, проксі-сертифікати дозволяють користувачеві фактично делегувати безліч посвідчень особи (особа користувача) до іншого користувача. Це вирішує проблему, оскільки B міг би використовувати проксі-сертифікат (підписаний А, звичайно), щоб довести, що він діє на користь A. Організація C потім прийняла б запит B.

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

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

3.2.5.3. Особливість

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

3.2.5.4. Створення проксі-сертифіката

Проксі-сертіфікат може використовуватися для делегації особи користувача до іншого користувача. Як можна це досягти в безпечній формі? Наприклад, припустимо що B потрібне посвідчення особи А, щоб виконати запит до C. Тому B потрібний проксі-сертифікат, підписаний А. Процесс створення цього сертифікату буде наступним:

· B створює відкриту/приватну пару ключів для проксі-сертифіката.

· B використовує пару ключів, щоб створити запит сертифікату, який буде відправлений А використовуючи безпечний канал. Цей запит сертифікату включає відкритий ключ проксі, але не приватний ключ.

· Імовірно А згоден делегувати його посвідчення особи до B, Організація А використовує приватний ключ, щоб підписати запит свідоцтва в цифровій формі.

· А посилає підписаний сертифікат назад до B, використовуючи безпечний канал.

· Тепер B може використовувати проксі-сертифікат, щоб діяти на користь A.

Важливе те, що приватний ключ проксі ніколи не передається між А і B. Це також торкається щодо приватного ключа A.

3.2.5.5. Підтвердження проксі-сертифіката

Звернемо увагу на C. Коли B посилає запит від імені А, і посилає C проксі-сертифікат, як може C перевірити правильність сертифікату? Іншими словами, як може C бути абсолютно упевнений, що B діє на користь A?

Процес перевірки достовірності прокси-сертификата практично ідентичний процесу перевірки достовірності звичайного сертифікату. Основна різниця в тому, що проксі-сертифікат не підписується у Центрі Сертифікації (CA), його підписує користувач. У даному прикладі, проксі-сертифікат підписаний А, який означає, що необхідний відкритий ключ A, щоб перевірити його достовірність. Оскільки С навряд чи має сертифікат A, запит, який використовує проксі-сертифікат зазвичай посилає сертифікат делегатора, щоб можна було перевірити правильність проксі-сертифіката. Коли сертифікат делегатора буде підписаний Центром Сертифікації, залишиться тільки перевірити правильність підпису Центру Сертифікації. На рис.№15 показано ланцюжок підписів проксі-сертифіката.

Рисунок 15. Підтвердження проксі-сертифіката

3.2.5.6. Додатково про проксі-сертификати

Існує безліч операцій, що виконуються з допомогою проксі-сертифікатів крім тих, що вже розглядалися. Наприклад, є можливість використовувати проксі-сертифікати для підпису інших проксі-сертификатів. Для детальнішого вивчення проксі-сертифікатів рекомендується прочитати RFC 3820, InternetX.509 Public Key Infrastructure Proxy Certificate Profile, доступний за адресою http://www.ietf.org/rfc/rfc3820.txt.

3.2.5.7. Контейнер, служба, і захист ресурсу

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

4. Засоби безпеки GRID - технологій

4.1. Сучасний стан програмного забезпечення інфраструктури GRID

На сьогодняшній день розроблено нове покоління програмного забезпечення GRID (ГПЗ). Представниками цього покоління є дві основні розробки: Globus Alliance випустив версію 4.0 комплексу Globus Toolkit, а робоча група Jra1 проекту EGEE випустила комплекс glite, читається "gee-lite".

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

Хоча концепція OGSA була сформульована ще в 2002 році, її проведення в життя виявилося досить важким. OGSA ввела поняття GRID -служб як основної форми програмних компонентів розподілених систем і вирішила завдання стандартизації взаємодії GRID - служб. Відповідні специфікації були розроблені в пропозиціях по інфрастуктурі GRID -служб OGSI і вперше реалізовані в Globus Toolkit 3. Далі історія розвивалася таким чином, що OGSI був переглянутий, і новий підхід отримав назву WSRF - Web-services Resource Framework.

Основним мотивом трансформації OGSI в WSRF став пошук компромісу між технологіями GRID- і Web-служб, що важливе перш за все з практичної точки зору, оскільки полегшується переклад вже наявних Web-додатків на технології GRID, а з іншого боку відкривається можливість використання в GRID розвиненого інструментарію. Рішення, запропоноване в WSRF, є надбудовою над Web-службами, що розширюють їх можливості засобами роботи з ресурсами, що запам'ятовують стан (stateful): WSRF - це п'ять доповнюючих стандарти Web-служб специфікацій, які дозволяють встановлювати зв'язок між Web-службами і ресурсами.

З’явилися перші реалізації WSRF. У Globus Toolkit 4.0 і glite це, відповідно, WS Core і Wsrf::lite. Ці компоненти містять контейнери (середовище функціонування) для грид-служб, а також API і засоби їх розробки. Маючи в своєму розпорядженні реалізацію WSRF, програмісти, зокрема прикладні, отримають інструментарій для створення служб із стандартними інтерфейсами і компоновки з них розподілених застосувань.

Друга особливість нового ГПЗ - розширений комплект служб. Версії Globus Toolkit з першої по третю містили лише служби для виконання дистанційних операцій, проте GRID - це просторово розподілена інфраструктура, що виконує роль операційного середовища для різних застосувань. Як підтверджує практика, щоб це середовище зберігало властивості звичайних комп'ютерних систем, в ній необхідне вирішення завдань забезпечення надійності та якості обслуговування, керованості, і вони починають реально вирішуватися службами планування, моніторингу завдань і пристроїв, обліку, протоколювання і так далі .

4.2. Програмне вирішення GLOBUS

Набір програм Globus Toolkit (GT) – програмний продукт з відкритим початковим кодом і набором бібліотек, розроблений в національній лабораторії. Він містить набір стандартних блоків і інструментів, які можуть бути використані розробниками і системними інтеграторами. За декілька років вийшли чотири версії програми Globus: оригінальна – в кінці дев'яностих, GT2 – в 2000, GT3 – в 2003, і GT4 – в 2005. Версія GT2 послужила базисом для безлічі GRID розробників по всьому світу. GT3 – стала першою повноцінною реалізацією інфраструктури GRID, побудованої на технології Web - сервісів, з використанням проміжної ланки GGF’s OGSI. GT4 – перша версія, повністю сумісна з основними Web - сервісами так само, як GRID - сервіси засновані на WSDL і WSRF. Більшість систем GRID використовують ОС UNIX.

Випущений стабільний реліз GT 4 Final, де зафіксовані всі зовнішні інтерфейси.

На сайті Globus Alliance приводиться опис складу служб GT 4 (Мал. 11), відомості про них, плани і стан реалізації.

Мал. 11. Компоненти Globus Toolkit 4.0

Для управління виконанням пакет надає можливість виявлення і управління ресурсами GRID, управління робочим простором і засобу планувальника співтовариства користувачів.

Для забезпечення безпеки пакет надає сервіси аутентифікації і авторизації, надання видаленого доступу і авторизації співтовариств користувачів.

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

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

Для підтримки спільної роботи система містить різні ядра Web – сервісів, бібліотеки і розширені функції підтримки введення/виводу.

GT4 містить набір стандартних служб. На даний момент вони представлені дев'ятьма Web - сервісними інтерфейсами, але їх число росте.

1. Управління завданнями: Пакет програм виявлення і управління ресурсами (GRAM);.

2. Надійна файлопередача (RFT);.

3. Делегування функцій.

4. Система моніторингу і виявлення вільних ресурсів – індекс (MDS - index);

5. Система моніторингу і виявлення – MDS - trigge.

6. Система моніторингу і виявлення – збір даних (MDS - aggregate);

7. Авторизація співтовариства (CAS);

8. Інтеграція і доступ до даним (OGSA - DAI);

9. Робота в реальному масштабі часу.

Слід зазначити, що Globus Toolkit не містить брокера ресурсів, залишаючи завдання його реалізації розробникам, що створюють системи GRID на його основі.