Захист Oracle E-Business Suite, Інші СУБД, Бази даних, статті







Все більшу поширеність останнім часом набувають корпоративні системи з доступом через тонкі клієнти. Яскравий приклад реалізації тонкого клієнта дає ERP-система Oracle E-Business Suite (OeBS), в якій доступ користувачів реалізований по протоколу HTTP / HTTPS із завантаженням необхідних додатків (аплетів Java) на робочу станцію користувача. Найбільш поширений доступ по HTTP, проте в даному протоколі не реалізовані криптографічні алгоритми, тобто з точки зору захисту інформації він має серйозний недолік. Таким чином, логічніше застосовувати захищену версію протоколу – HTTPS, яка представляє собою модифікацію протоколу HTTP із застосуванням криптографічного захисту в рамках SSL. Протокол SSL (Secure Socket Layer), в свою чергу, реалізований так, щоб забезпечити сумісність з кінцевими клієнтами в частині використовуваних криптографічних алгоритмів для шифрування і контролю цілісності переданих даних.


“Домовившись” про набір криптоалгоритмів в рамках “рукостискання”, SSL-клієнт і сервер встановлюють захищене з’єднання. Враховуючи, що в Oracle E-Business Suite в якості HTTP-сервера використовується Oracle HTTP Server (OHS), реалізований на базі Apache, все було б досить просто – якщо б настройка SSL зводилася тільки до налаштування Oracle HTTP Server. Однак це не так: Oracle E-Business Suite має багатоланкову архітектуру, і в ній, крім Oracle HTTP Server, для взаємодії з користувачами застосовується також служба Oracle Forms. Відповідно необхідно налаштовувати SSL і в даній службі.


Для налаштування Oracle E-Business Suite рекомендується утиліта AutoConfig, яка використовує для цілей централізованої налаштування всіх програм Oracle E-Business Suite файл контексту. Даний файл являє собою перелік змінних OeBS та їх значень у форматі XML. Таким чином, замість внесення змін безпосередньо в конфігураційні файли служб Oracle (Oracle HTTP Server, Oracle Forms) ці зміни слід вносити в файл контексту і далі за допомогою утиліти AutoConfig поширювати їх на сервіси OeBS.


В принципі процес налаштування SSL для служб OeBS описаний в документі Oracle Note 123718.1 A Guide to Understanding and Implementing SSL with Oracle Applications, але, як показала практика, даний документ не повністю відображає всі тонкощі налаштування SSL. Крім того, в ньому зроблено багато припущень, які зовсім не обов’язково застосовні до кінцевої системі. Наприклад, у частині налаштування SSL для Oracle Forms передбачається, що кореневий сертифікат засвідчує, вже міститься в дистрибутиві віртуальної машини Java від Oracle (JInitiator), однак це справедливо тільки в тому випадку, якщо кореневий сертифікат для Oracle Forms придбаний у одного з довірених засвідчують центрів (Verisign, Thawte і т. д.), що, очевидно, не завжди відповідає дійсності.


Заради точності зазначимо, що наш екземпляр Oracle E-Business Suite встановлювався на платформі Red Hat Linux ES3 x86. Таким чином, команди, наведені нижче, справедливі для цієї платформи та інших Unix-платформ і будуть відрізнятися (головним чином в кінці дороги і синтаксису) для платформи Windows.


Отже, конфігурація контексту можна виконати трьома способами:



  • безпосередньо редагуючи файл контексту (він розміщений на шляху, що дорівнює значенню змінної $CONTEXT_FILE );
  • використовуючи утиліту командного рядка txkrun.pl ;
  • використовуючи Web-інтерфейс Oracle Applications Manager.

Ми рекомендуємо користуватися другим і третім способами, так як при безпосередньому внесення змін до файл контексту великий ризик помилки. Природно, ми рекомендуємо зробити резервну копію файлу контексту перед внесенням будь-яких змін.


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



  • користувач звертається по HTTPS на URL початкової сторінки Oracle E-Business Suite;
  • сервер аутентифікує себе для користувача, пред’являючи сертифікат;
  • користувач підтверджує аутентифікацію сервера і аутентифікує себе по імені і паролю;
  • сервер допускає користувача на робочу сторінку, що генерується з урахуванням ролі користувача в системі;
  • користувач звертається за гіперпосиланням для завантаження необхідного йому аплету Java;
  • сервер повертає користувачеві аплет Java по протоколу HTTPS;
  • користувач запускає аплет допомогою віртуальної машини Java від Oracle (JInitiator);
  • аплет взаємодіє з сервером Forms по протоколу HTTPS, використовуючи для цього сервлет, що запускається на стороні сервера.

У конфігурації за замовчуванням взаємодія ведеться по протоколу HTTP. Взаємодія аплету Java з сервером Forms відбувається через виділений порт на сервері Oracle E-Business Suite (TCP/9000); отже, дане взаємодія зажадає сформувати додаткове дозвільне правило на межсетевом екрані.


Таким чином, необхідно виконати наступні спільні кроки:



  • генерація ключового матеріалу;
  • переклад сервера Oracle HTTP Server в режим HTTPS;
  • переклад сервера Forms в режим взаємодії через сервлет;
  • настройка робочого місця користувача.

Генерація ключового матеріалу


В принципі для генерації ключового матеріалу можна використовувати будь-які технічні засоби, наприклад, ПО OpenSSL. Однак розумніше для цих цілей задіяти корпоративну інфраструктуру відкритих ключів, якщо така розгорнута. Формування сертифіката виконується за стандартним запитом на сертифікат формату PKCS # 10; при цьому слід врахувати, що сертифікат повинен формуватися на ім’я, рівне повного доменному імені (FQDN – Fully Qualified Domain Name) сервера OHS / Forms. Сервер OHS підтримує роботу як з звичайними файлами ключового матеріалу формату PEM, так і з контейнерами PKCS # 12, згенерували з використанням ПО Oracle Wallet Manager. Сервер Forms підтримує тільки контейнери Wallet.


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


Таблиця 1. Склад змінних контексту для налаштування ключового матеріалу в OHS






















Мінлива


Коментар


s_web_ssl_directory


Директорія для розміщення конфігураційних файлів


s_web_ssl_keyfile


Повний шлях до файлу секретного ключа сервера


s_web_ssl_certfile


Повний шлях до файлу сертифіката сервера


s_web_ssl_certchainfile


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


s_websrv_wallet_file


Шлях до директорії, в якій розміщений контейнер PKCS # 12, сформований з використанням ПО Oracle Wallet Manager


Для встановлення довіри до сертифіката сервера на стороні клієнта кореневі сертифікати, ключами яких підписується сертифікат сервера OHS, повинні бути додані в локальне сховище сертифікатів на робочому місці користувача.


Для роботи Forms з підтримкою SSL сервер Forms також повинен бути налаштований для імпорту ключового матеріалу. Обов’язкова умова для сервера Forms – формат ключового матеріалу Oracle Wallet. Взагалі кажучи, Wallet являє собою звичайний контейнер PKCS # 12, так що можлива конвертація контейнерів Wallet в контейнери OpenSSL (PEM) і назад. ПО Oracle Wallet Manager завжди зберігає контейнери з фіксованим ім’ям і розширенням. При зазначеної опції Auto Login (ПО Oracle Wallet Manager, меню Wallet) зберігається два файли: ewallet.p12 і cwallet.sso. Перший являє собою той самий контейнер PKCS # 12, в якому зберігається ключовий матеріал (секретний ключ сервера, захищений паролем, сертифікат сервера, сертифікати довірених УЦ). Другий файл – це контейнер, сконвертовані з PKCS # 12 для підтримки автоматичного запуску служб, які використовують Wallet як сховище ключового матеріалу.


При формуванні ключового матеріалу дотримуються ті ж правила, які застосовувалися при формуванні ключового матеріалу для сервера OHS (наприклад, кінцеве ім’я сертифікату повинна дорівнювати повного доменному імені сервера Forms).


Налаштування Oracle HTTP Server


Незважаючи на те, що Oracle HTTP Server є похідним від поширеного Web-сервера Apache, він конфігурується не шляхом редагування файлу httpd.conf, а через установку відповідних змінних контексту. У частині підтримки SSL редагуванню піддається ряд змінних контексту (вони наведені в табл. 2).


Таблиця 2. Склад змінних контексту для налаштування SSL і їх значення


 











































































Мінлива


Значення


Коментар


url_protocol


https


Прикладний протокол, що повертається користувачеві, у складі URL гіперпосилань


s_web_ssl_directory


/apps/apps/Apache/Apache/conf


Директорія, в якій розміщуються конфігураційні файли OHS


s_web_ssl_certfile


/apps/apps/Apache/Apache/conf/ssl.crt/apps.test.ot.crt


Повний шлях (включаючи ім’я файлу), в якому розміщений сертифікат сервера OHS


s_web_ssl_certchainfile


/apps/apps/Apache/Apache/conf/ssl.crt/test.ot.chain.crt


Повний шлях (включаючи ім’я файлу), в якому розміщена ланцюг сертифікатів для встановлення довіри до сертифіката сервера OHS


s_web_ssl_keyfile


/apps/apps/Apache/Apache/conf/ssl.key/apps.test.ot.key


Повний шлях (включаючи ім’я файлу) до секретного ключа OHS


s_webentryurlprotocol


https


Прикладний протокол, по якому відбувається взаємодія користувачів з OeBS


s_webport


4443


Номер порту TCP, за яким відбувається взаємодія


s_webssl_port


4443


Номер порту TCP, за яким відбувається взаємодія в захищеному режимі


s_apps_portal_url


https://apps.test.ot:4443/pls/VIS_portal30/portal30.home


Покажчик URL, за яким розташовано додаток Applications Portal


s_chronosURL


https://apps.test.ot:4443/oracle_smp_chronos/oracle_smp_chronos_sdk.gif


Покажчик URL, за яким розташовано додаток Chronos


s_disco_port


4443


Порт TCP, за яким відбувається взаємодія з додатком Discoverer


s_disco_protocol


https


Прикладний протокол, по якому відбувається взаємодія з додатком Discoverer


s_discoinstance


apps.test.ot_4443


Ім’я екземпляра додатку Discoverer виду <доменне ім'я сервера> _ <значення змінної s_disco_port>


s_f60map


https://apps.test.ot:4443/OA_TEMP


URL, що повертається користувачеві для звернення до аплетам сервера Forms


s_webcache_http_port


4443


Порт, по якому відбувається взаємодія через Oracle Webcache по протоколу HTTP


s_webcache_https_port


4443


Порт, по якому відбувається взаємодія через Oracle Webcache по протоколу HTTPS


s_webcache_url_protocol


https


Прикладний протокол, по якому відбувається взаємодія через Oracle Webcache


Припустимо, повне доменне ім’я нашого сервера додатків – apps.test.ot, тоді для перемикання в режим SSL перерахованим змінним слід встановити значення згідно табл. 2.


Як видно з табл. 2, в якості порту для SSL обраний порт 4443. Справа в тому, що, як правило, служби Oracle встановлюються і працюють з правами, відмінними від прав суперкористувача (root). Таким чином, за замовчуванням службам Oracle недоступні порти TCP діапазону 1-1024.


Конфігурування для підтримки SSL можливо через графічний Web-інтерфейс з використанням майстрів (Configuration Wizards) Oracle Applications Manager. Майстри для автоматизації конфігурування поставляються у складі поновлення Oracle Applications Manager Minipack 11i.OAM.H. Інтерфейс конфігурування при цьому виглядає, як показано на рис. 1.










Fig.1

 

Рис. 1. Графічний інтерфейс Configuration Wizards.


Якщо оновлення від Oracle, що надає можливість конфігурування через Oracle Applications Manager, не встановлено, для цілей конфігурації можна використовувати сценарій txkrun.pl. Даний сценарій написаний на мові Perl і призначений для автоматизованого внесення змін в контекст за допомогою вказівки параметрів у командному рядку. У табл. 3 представлені основні ключі, які передаються сценарієм txkrun.pl через командний рядок.


Таблиця 3. Глобальні параметри Configuration Wizards
























Параметр


Значення


Опис


Script


SetAdvCfg


Сценарій Configuration Wizards для виконання


Appsuser


<Ім'я користувача>


Ім’я користувача Oracle Applications (за замовчуванням – apps)


Appspass


<Пароль>


Ім’я користувача Oracle Applications (за замовчуванням – apps)


Enable
disable


<Опція>


Опція для включення / відключення


Для налаштування SSL при доступі до OHS потрібно передати сценарієм txkrun.pl параметри, наведені в табл. 4.


Таблиця 4. Параметри Configuration Wizards для налаштування SSL




















Параметр


Значення


Опис


enable


SSL


Завдання конфігурації SSL


s_webssl_port


4443


Порт TCP, на якому OHS буде приймати з’єднання SSL


s_web_ssl_directory


$COMMON_TOP/admin/certs/apache/


Директорія, в якій зберігається ключовий матеріал OHS у форматі OpenSSL (PEM)


У підсумку повна командний рядок для запуску Configuration Wizards для підтримки SSL на сервері OHS буде виглядати наступним чином:


$ txkrun.pl -script=SetAdvCfg -appsuser=apps -appspass=apps -enable=SSL -s_webssl_port=4443 -s_web_ssl_directory=”$COMMON_TOP/admin/certs/apache/”


Повний склад команд сценарію txkrun.pl описаний в документі Metalink Note # 277574.1


Налаштування Oracle Forms


За замовчуванням при установці Oracle E-Business Suite режим SSL відключений, Oracle Forms Server працює в режимі Listener (приймає з’єднання на порт TCP/9000). Для підтримки SSL в додатках Forms ми рекомендуємо переналаштувати сервер Forms на взаємодію через сервлет. Взаємодія з сервером Forms в даному випадку відбувається по протоколу HTTP (S) за стандартними портам Oracle HTTP Server. Режим роботи сервера Forms визначається змінної контексту s_frm_connect_mode . Відповідно дана змінна може мати такі значення:



  • socket – режим за умовчанням;
  • http – для взаємодії по протоколу HTTP;
  • https – для взаємодії по протоколу HTTPS.

В нашому випадку, очевидно, слід встановити значення змінної s_frm_connect_mode рівним https. Проте в даному випадку трафік взаємодії клієнтів з сервером Forms зростає приблизно на 40%, оскільки фактично виконується інкапсуляція трафіку Forms в HTTP (S). До того ж слід врахувати, що трафік HTTPS як зашифрований не піддається компресії.


Режим роботи сервера Forms через сервлет підтримується починаючи з Forms6i Patchset 7. Необхідно також, щоб сервер Forms був встановлений на одному вузлі (tier) з сервером OHS.


Директорія, в яку збережений Wallet, що містить ключовий матеріал для сервера Forms, визначається змінної контексту s_frmWalletDir .


Для перемикання Forms в режим сервлета задається значення змінної контексту s_forms_servlet_serverurl . Для задіяння змінної слід задати її значення рівним відносного шляху до сервлету, наприклад:


<server_url oa_var=”s_forms_servlet_serverurl”>/forms/formservlet</server_url>


Після внесення змін у файл контексту необхідно поширити дані зміни, виконавши сценарій adautocfg.sh , Який, спираючись на значення змінних контексту, конфігурує компоненти Oracle E-Business Suite.


Перемикання в режим сервлета можливо через графічний інтерфейс Oracle Applications Manager (посилання Forms Listener Servlet). Для активації даної опції слід вибрати Enable і слідувати інструкціям Configuration Wizards.


Для перемикання сервера Forms в режим сервлета також можна скористатися утилітою txkrun.pl , Виконавши наступну команду:


$ txkrun.pl -script=SetAdvCfg -appsuser=apps -appspass=apps -enable=FormsLsnrServlet


Проте значення змінної s_frm_connect_mode необхідно встановити в https вручну у файлі контексту. Можливо, даний недолік буде виправлений в майбутніх релізах.


Після виконання сценарію txkrun.pl та виправлення контексту необхідно виконати конфігурування OeBS з використанням AutoConfig (сценарій adautocfg.sh ). Необхідно також провести перезапуск всіх служб, виконавши послідовно команди:


sh $ COMMON_TOP / admin / scripts / <ім'я контексту> / adstpall.sh apps / apps


sh $ COMMON_TOP / admin / scripts / <ім'я контексту> / adstrtall.sh apps / apps


Налаштування клієнтського ПЗ


Так як взаємодія користувача з OeBS здійснюється фактично через два прикладних компонента: Інтернет-браузер і віртуальну машину JInitiator, настройку даних компонентів і встановлення довіри необхідно провести для кожного компонента окремо. Налаштування довіри полягає в додаванні в сховища сертифікатів браузера і JInitiator кореневого сертифіката (ланцюга сертифікатів) інфраструктури відкритих ключів, яка обслуговує Oracle E-Business Suite. У частині браузера використовується сховище операційної системи; ПО JInitiator для даних цілей використовує файл certdb.txt , В який поміщені сертифікати засвідчують центрів у форматі PEM.


Таким чином, для встановлення захищеного взаємодії необхідно, щоб у сховищі сертифікатів робочої станції, з якої здійснюється доступ, були поміщені кореневий сертифікат інфраструктури, обслуговуючої OEBS, і сертифікат сервера, а в файл c:program filesoraclejinitiator 1.3.1.18libsecuritycertdb.txt – Кореневий сертифікат (ланцюг сертифікатів) інфраструктури, яка обслуговує OEBS, у форматі PEM (рис. 2). При приміщенні ланцюга сертифікатів в файл certdb.txt сертифікат засвідчує центру, який підписав безпосередньо сертифікат сервера, повинен бути поміщений вище сертифікату кореневого засвідчує центру.










Fig.2

 

Рис. 2. Редагування файлу certdb.txt.


З технічної точки зору внесення змін до дистрибутив JInitiator в файл certdb.txt не становить проблеми (при наявності комплекту ПО InstallShield), проте проблеми можуть виникнути в плані ліцензійного угоди та авторського права компанії Oracle на ПО JInitiator. З даної ситуації існує три виходи.


  • Внесення змін до certdb.txt адміністратором вручну на кожній робочій станції. Очевидно, даний варіант можливий тільки при невеликій кількості робочих станцій у віданні адміністратора.
  • Централізоване поширення файлу certdb.txt через служби OeBS (наприклад, гіперпосилання на файл, розміщений в директоріях Oracle HTTP Server) з відповідним інструктажем користувачів. Даний варіант можливий тільки за наявності у користувачів прав локального адміністратора їх АРМ.
  • Централізоване поширення файлу certdb.txt через інші служби централізованого управління (наприклад, групові політики доменів Windows, служби Novell).

    Відновлення початкових налаштувань


    Якщо внесення перерахованих вище змін спричинило порушення роботи OEBS, можна відновити настройки, які були до внесення змін. Для цього необхідно відновити з резервної копії файл контексту (змінна оточення $CONTEXT_FILE ) І запустити процедури AutoConfig з перезапуском всіх служб OEBS.


    Висновок


    В даній статті наведено методику настройки додатків Oracle E-Business Suite, що дозволяє провести односторонню аутентифікацію сервера по відношенню до користувача, а також встановити захищене взаємодія користувачів з цими додатками. Логічним розвитком даної методики представляється реалізація двосторонньої аутентифікації з використанням сертифікатів X.509 на стороні як сервера, так і клієнта. Для посилення даного методу аутентифікації можливо також використовувати носії e-token для зберігання ключового матеріалу. На жаль, в установках Oracle E-Business Suite 1.5.9 та 1.5.10 метод аутентифікації клієнтів за сертифікатами відсутній, для реалізації даного методу необхідно встановлювати і налаштовувати служби Oracle Single Sign-On. Дана тематика слабо документована і, таким чином, заслуговує окремої статті.

  •  

    Схожі статті:


    Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

    Коментарів поки що немає.

    Ваш отзыв

    Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

    *

    *