1. Серія контенту:
2. Цей контент є частиною серії: SSL і ISC
3. Знайомство з SSL
4. цифрові сертифікати
5. типи сертифікатів
6. Аутентифікація на стороні клієнта або сервера
7. Малюнок 1. Процес аутентифікації між клієнтом і сервером
8. SSL і WebSphere Application Server
9. Малюнок 2. Багаторівнева безпеку WebSphere Application Server
10. SSL і Integrated Solutions Console
11. Які переваги дає використання SSL?
12. Ресурси для скачування

SSL і ISC

Забезпечення безпеки даних у відкритих комунікаційних каналах при роботі з ISC

Серія контенту:

Цей контент є частиною # з серії # статей: SSL і ISC

https://www.ibm.com/developerworks/ru/views/global/libraryview.jsp?series_title_by=ssl+и+isc

Слідкуйте за виходом нових статей цієї серії.

Цей контент є частиною серії: SSL і ISC

Слідкуйте за виходом нових статей цієї серії.

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

Протокол SSL (Secure Socket Layers - протокол захищених сокетів), спільно розроблений Netscape Communications і RSA Data Security, дозволяє ефективно забезпечити таку безпеку. Протокол SSL забезпечує безпеку, аутентифікацію на базі сертифікатів і узгодження безпеки за встановленим мережному з'єднанню, тому безліч компаній і продуктів прийняли SSL в якості комунікаційного протоколу.

У цій серії ми сконцентруємося на двох головних аспектах:

1. Детальна інформація про схему роботи SSL;
2. детальна інформація про підтримку SSL в версіях 5.1 і 6.0.1 середовища ISC.

В даній статті досліджується SSL і пояснюється, чому його рекомендується реалізувати в середовищі ISC. У другій і третій частинах цієї серії буде представлена ​​докладна покрокова інструкція по реалізації та підключення SSL до ISC 5.1 і 6.0.1.

По-перше, що таке SSL?

Знайомство з SSL

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

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

цифрові сертифікати

Це підводить нас до обговорення цифрових сертифікатів, що грають важливу роль в SSL. Цифрові сертифікати в основному служать двом цілям:

• встановити особу власника;
• зробити доступним первинний ключ власника.

Цифровий сертифікат випускається перевіреної повноважною організацією - джерелом сертифікатів (certificate authority - CA) і видається тільки на обмежений час. Після закінчення терміну дії сертифіката його необхідно замінити. Протокол SSL використовує цифрові сертифікати для обміну ключами, аутентифікації серверів і, при необхідності, аутентифікації клієнтів.

Цифровий сертифікат містить наступні фрагменти інформації про особу власника сертифіката і джерелі сертифікатів:

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

Підключення по SSL завжди ініціюється клієнтом викликом URL-адреси, що починається з https: // замість http: //.

типи сертифікатів

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

Є три способи отримати SSL-сертифікат:

1. використовувати сертифікат від джерела сертифікатів;
2. використовувати самоподпісанний сертифікат;
3. використовувати "порожній" сертифікат

Використання сертифікату від джерела сертифікатів

Джерела сертифікатів (CA) - це організації, яким довіряє вся галузь і які займаються видачею сертифікатів у режимі онлайн. Наприклад, такий сертифікат можна отримати від компанії VeriSign. Щоб отримати сертифікат, підписаний джерелом, необхідно надати достатньо інформації джерела, щоб він зміг перевірити вашу особистість. Тоді джерело створить новий сертифікат, підпише його і доставить його вам. Популярні Web-браузери заздалегідь налаштовані довіряти сертифікатам, виданим певними джерелами, так що не потрібно ніякої додаткової конфігурації для підключення клієнта через SSL до сервера, для якого був виданий сертифікат.

Використання самоподпісанного сертифіката

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

Використання "порожнього" сертифіката

Це рішення по функціональності нічим не відрізняється від попередніх. У загальних рисах, "порожні" сертифікати містять фіктивну інформацію, використовувану в якості тимчасового рішення для настройки SSL і перевірки його функціонування в конкретному середовищі. Додаток ISC надає "порожній" сертифікат разом з ключами і файлами довірених джерел для сервера і клієнта.

Отже, що потрібно робити після отримання сертифікату?

Аутентифікація на стороні клієнта або сервера

Після того як сертифікат був отриманий, необхідно встановити його автентичність (аутентифицировать). У протоколі SSL є два типи аутентифікації:

• аутентифікація на стороні клієнта;
• аутентифікація на стороні сервера.

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

SSL-аутентифікація клієнта дозволяє серверу перевірити особу користувача. Використовуючи ті ж прийоми, що і у випадку з аутентифікацією сервера, серверне ПЗ з підтримкою SSL може перевірити, що сертифікат клієнта і відкритий ключ дійсні і були видані джерелом сертифікатів, які є в списку довірених джерел сервера. Це підтвердження може бути важливим, якщо, наприклад, сервер - це банк, що відправляє конфіденційну фінансову інформацію замовнику, і він хоче перевірити особу одержувача.

На малюнку 1 наведена діаграма, що ілюструє цей процес.

Малюнок 1. Процес аутентифікації між клієнтом і сервером

Файл ключів і файл зі списком довірених джерел

Реалізація протоколу SSL, яка використовується в WebSphere® Application Server, зберігає персональні сертифікати в файлі ключів SSL і сертифікати видавця в файлі зі списком довірених джерел. Файл ключів містить колекцію сертифікатів, кожен з яких може бути представлений під час установки SSL з'єднання для підтвердження автентичності. У файлі зі списком довірених джерел зберігається колекція сертифікатів, які вважаються достовірними і з якими буде порівнюватися представлений сертифікат під час установки SSL-з'єднання для перевірки автентичності.

SSL і WebSphere Application Server

Хорошим прикладом реалізації протоколу SSL є його підтримка в IBM® WebSphere Application Server. Система безпеки цього сервера має багаторівневу архітектуру, показану на малюнку 2.

Малюнок 2. Багаторівнева безпеку WebSphere Application Server

Рівень мережевої безпеки забезпечує аутентифікацію на транспортному рівні, цілісність і шифрування повідомлень. Комунікації між різними серверами WebSphere Application Server можуть бути налаштовані на використання протоколів SSL і HTTPS. Для додаткового захисту повідомлень також можна використовувати протоколи IP Security і VPN (Virtual Private Network - віртуальна приватна мережа).

Протокол SSL забезпечує безпеку на транспортному рівні: аутентифікацію, цілісність і конфіденційність для безпечного з'єднання між клієнтом і сервером в WebSphere Application Server. Цей протокол працює поверх TCP / IP і під прикладними протоколами, такими як HTTP, LDAP, IIOP, забезпечуючи достовірність і таємність переданих даних. Залежно від конфігурації SSL на клієнті і сервері можуть бути встановлені різні рівні достовірності, цілісності даних і секретності. Розуміння основ функціонування протоколу SSL дуже важливо для правильного налаштування і досягнення необхідного рівня захисту для даних клієнта і додатки.

Деякі функції безпеки, які надаються протоколом SSL:

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

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

Протокол SSL використовується різними компонентами всередині WebSphere Application Server для забезпечення достовірності та конфіденційності. До цих компонентів відносяться: вбудований HTTP-транспорт, ORB і безпечний LDAP-клієнт.

Реалізація SSL, яка використовується в WebSphere Application Server, - це або розширення для Java - IBM Java ™ Secure Sockets Extension (IBM JSSE), або IBM System SSL. Провайдер IBM JSSE містить еталонну реалізацію, підтримуючу протоколи SSL і TLS (Transport Layer Security - безпека транспортного рівня) і API для інтеграції. З провайдером IBM JSSE також поставляється стандартний провайдер, що надає підтримку RSA для функціональності цифрового підпису з бібліотеки JCA (Java Cryptography Architecture - Архітектура Шифрування для Java) для платформи Java 2, стандартні набори шифрів для SSL і TLS, менеджерів довірених джерел сертифікатів і ключів, що використовують технологію X509, і реалізацію технології PKCS12 для сховища цифрових сертифікатів JCA.

Конфігурація провайдера JSSE дуже схожа на конфігурацію більшості інших реалізацій SSL, наприклад GSKit, проте пару відмінностей слід виділити:

• Провайдер JSSE підтримує зберігання власного сертифіката та сертифікатів видавця в файлі ключів SSL, але він також підтримує і окремий файл, т.зв. файл джерел сертифікатів (trust file). Цей файл може містити тільки сертифікати джерел. Можна помістити свої власні сертифікати в файл ключів SSL, а сертифікати видавців - в trust-файл. Це може знадобитися, наприклад, при наявності недорогого апаратного криптографічного пристрої, у якого пам'яті досить тільки для зберігання персонального сертифіката. У цьому випадку файл ключів вказує на апаратний пристрій, а trust-файл вказує на файл на диску, що містить всі сертифікати видавців.
• Провайдер JSSE не розпізнає спеціальний формат файлу ключів SSL, який використовується плагіном - файли з розширенням .kdb. Провайдер JSSE розпізнає тільки стандартні формати файлів, такі як Java Key Store (JKS - сховище ключів Java). Спільне використання файлів ключів SSL плагіном і сервером додатків неможливо. Більш того, для керування ключами сервера додатків і trust-файлами необхідно використовувати різні реалізації утиліти управління ключами.

SSL і Integrated Solutions Console

Додаток ISC - це єдине середовище Web-консолей адміністрування для розгортання та інтеграції консольних модулів, що дозволяє замовникам управляти рішеннями, а не конкретними продуктами IBM. Це середовище включає в себе контейнер портлетів, Java-компоненти (JMX) для управління додатками і модулі довідки Eclipse.

Для реалізації конфіденційності та шифрування можна використовувати протокол SSL. За допомогою SSL можна захистити взаємодію між Web-браузером користувача та сервером ISC. Шифрування важливо тому, що в ISC використовується аутентифікація, заснована на формах; при цьому ідентифікатор і пароль користувача для входу в систему не зашифровано при пересиланні по мережі. Якщо консольного модулю потрібен доступ до внутрішніх ресурсів через безпечне з'єднання, його портлет можуть використовувати SSL.

Які переваги дає використання SSL?

Чому це так важливо? Безпечна і ефективна передача даних по відкритим комунікаційним каналам - це критичний компонент забезпечення функціонування сучасної ІТ-системи, і протокол SSL дозволяє забезпечити цю безпеку. Однак підключення SSL до середовища ISC може виявитися складним і трудомістким завданням. У чому складність цього завдання? Питання безпеки даних в середовищі Web-додатків, подібних середовищі Integrated Solutions Console, може здатися трохи розмитим для новачків, тому що безпека ІТ сама по собі - вкрай широка область, що охоплює багато різних аспектів у відкритих комунікаційних мережах.

У наступних двох статтях цієї серії буде представлена ​​організація безпеки даних на основі SSL в середовищі, заснованої на Integrated Solutions Console. Спочатку ми розглянемо настройку і включення SSL для Integrated Solutions Console 5.1 з використанням порожнього, власного і випущеного видавцем сертифікатів, а потім розберемо, як виконати ті ж дії для Integrated Solutions Console 6.0.1.

Ресурси для скачування

Схожі теми

• SSL on ISC, Part 1: What is SSL and why should I care? (EN) : Оригінал статті.
• Self-signed server certificate (EN) : Покрокова інструкція по створенню власного сертифіката
• IBM Workplace Collaboration Services information center (EN) : В цій статті пояснюється, які саме компоненти в різних Web-браузерах вимагають підписаних перевірених сертифікатів.
• WebSphere Application Server and IBMJSSE (EN) - на цій сторінці ресурсу InfoCenter приведена додаткова інформація по SSL.
• Launch the ISC console thru Web Browser (EN) : В цій статті показано, як запустити Integrated Solutions Console через Web-браузер після установки. (EN)
• Embed the Integrated Solutions Console installation (EN) (DeveloperWorks, березень 2005 року): ця стаття демонструє, як за допомогою установника вбудовувати Integrated Solutions Console в інші продукти.
• Додаткова інформація за Java , продуктам Tivoli і WebSphere products , Eclipse , безпеки а також безпеки мається на відповідних розділах сайтів developerWorks і alphaWorks.
• скачайте версію Integrated Solutions Console і ознайомтеся з додатковою інформацією про цей продукт в Autonomic Computing Toolkit. (EN)
• WebSphere Application Server 6.1 - це платформа для додатків на базі Java 2 Enterprise Edition і Web-сервісів. Крім звичайної версії, пропонуються також версія Express (Що включає сервер додатків J2EE, приклади додатків, інструменти розробника і майстри), а також безкоштовна спрощена версія Community Edition . (EN)

Підпишіть мене на повідомлення до коментарів