Розробка системи керування та актуалізації інформації web-сайту національного оператора енергоринку

- адрес електронної скриньки, яка використовується в поштовій системі;

Серед елементів управління є дві кнопочки «Примінити» та «Скасувати»

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

«Скасувати» - не робить ніяких змін, а переадресовує користувача до головного меню системи адміністрування.

Вихід.

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



3.7.1 Розробка системи нормалізації данних

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

Блок схема алгоритму нормалізації даних.

3.7 Технічні засоби, що використовуються

Для повно функціональної:системи адміністрування роботи сайту "Національного оператора енергоринку".

Мінімальна конфігурація системи повинна включати:

процесор - не менш ніж Intel Pentium 2 (200 MHz);

оперативна пам`ять - не менш ніж 32 Мб;

вільне місце на жорсткому диску - не менш 20 Мб (не враховуючи місце, що займає база даних, СУБД MySQL (необхідне тільки на сервері));

принтер (в випадку, якщо необхідно вивести дані на друк).

монітор, що підтримує розрішення 1024ч768х16.

відео карта, що має не менш ніж 4 Мб пам`яті.

5 Мб місця на жорсткому носії для збереження тимчасової інформації у кеші.

Бажана конфігурація системи повинна включати:

процесор - Pentium 4 (2.4 GHz);

оперативна пам`ять - 512 Мб;

принтер;

.монітор, що підтримує розрішення 1280х1024х32

відео карта, що має 64 Мб пам`яті;

наявність мережевої плати та комп`ютерної мережі;

RAID-контролер із двома жортскими дисками;

джерело бесперебійного живлення;

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

4. Організація захисту даних на рівні крупного державного підприємства

4.1 Захист від втрати інформації внаслідок збоїв

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

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

Щоб вибудувати ефективну систему збереження інформації, слід визначити її основні параметри:

вартість даних, що захищаються. Цей параметр визначає максимальну вартість засобів, що має сенс затратити на захист даних;

максимально можлива втрата. Цей параметр визначає частоту резервного копіювання даних;

максимально припустимий час відновлення. Цей параметр визначає наявність або відсутність необхідності в "гарячому" резервуванні системи.

Проблему надійного збереження даних "просто" вирішити, якщо встановити пару файл-серверів, що працюватимуть паралельно, та забезпечити оперативну заміну всіх компонентів системи, включаючи процесори. Однак для домашнього комп'ютера такі витрати є зовсім зайвими, а для підприємства виправдані за умови, коли навіть незначне простоювання техніки обертається великими збитками. Усі способи захисту даних від утрати будуються на їх дублюванні. Фізичний рівень захисту використовує так звані "дзеркальні" диски, логічний рівень передбачає створення копій. Найпростішим засобом захисту від втрати данних е застосування пристрою безперебійного живлення. Надійний захист від утрати даних може бути створено лише з використанням обох рівнів. Якщо у вас працюють два "дзеркальні" диски, то вони захистять дані при відмові одного з них. Однак у разі ушкодження файлової системи вони не допоможуть. Навіть встановлений у комп'ютер RAID-контролер із двома дисками не замінить регулярного резервного копіювання даних. Без сумніву, резервне копіювання - надійний і необхідний спосіб збереження і захисту даних. Частота його використання і спосіб копіювання залежать від конфігурації системи і характеру даних.

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

4.1.1 Захист данних на фізичному та логічному рівні

Для захисту Web сайту підприємства на належному рівні коли незначне простоювання обертається великими збитками виправданий високий рівень захисту інформації від втрати в наслідок збоїв.Web сайт Національного оператора енергоринку розміщений на сервері який належно захищений на фізичному рівні. Сервер в першу чергу орієнтований на оперативну заміну всіх компонентів системи, включаючи процесори. Від перепадів напруги сервер захищений джерелом безперебійного живлення. На сервері використовується оперативна пам'ять з корекцією помилок і встановлений RAID-контролер із двома "дзеркальними" дисками які захистять дані при відмові одного з них. Однак дзеркальні диски не допомагають у разі ушкодження файлової системи.

Оскільки захист від збоїв на фізичному рівні не дає потрібної надійності виникає потреба захисту даних на логічному рівні. Захист від збоїв на логічному рівні відбувається шляхом резервного копіювання даних за допомогою програмних засобів. Для захисту Web сайту Національного оператора енергоринку був створений сценарій "copy.php" який виконує резервне копіювання даних на файловий сервер - це дозволяє зберегти данні та відновити роботу Web сайту у випадку програмного збою.

Також існує можливість запуску системи резервного копіювання вручну з системи управління Web сайтом шляхом вибору в головному меню системи управління пункту "Захист від збоїв" з наступним вибором одного з підпунктів.

Повне резервне копіювання.

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

4.2 Захист даних від зовнішніх атак

4.2.1 Рішення захисту корпоративних інформаційних систем

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

В інформаційній технології Intranet ключове місце займає Intranet-сервер, названий також WWW-сервером (веб-сервером). WWW-сервер може розглядатися як специфічна платформа для побудови інформаційної системи. Архітектура WWW-сервера залежить від функціональної спрямованості інформаційної системи, що буде будуватися на його основі. Проте можна виділити кілька типових рішень для веб-серверів в рамках корпоративної інформаційної системи. У випадку роботи в рамках глобальних мереж загального або обмеженого доступу використається зовнішній інформаційний сервер. Зовнішній інформаційний сервер може бути створений для представницьких (інформація про організацію і її роботи), технологічних (абоненти одержують доступ до технічних матеріалів, новим версіям програмних систем і так далі), маркетингових і інших цілей. Специфікою описаної моделі є мінімальна інформація про користувача, необхідність роботи в потенційно ворожому середовищі. У цьому зв'язку виникає необхідність захисту WWW - серверів. Особливо це актуально для внутрішніх і зовнішніх інформаційних серверів. Для рішення подібних завдань необхідний комплексний підхід до захисту інформації.

Типова інфраструктура корпоративної АС (Рис. 1) включає зону Інтернет, у якій перебувають потенційні клієнти і яка не є безпечної, демілітаризовану зону, у якій перебувають доступні з Інтернет Web-сервера, і захищену зону Інтранет, у якій циркулює внутрішня інформація. Насамперед, існує Інтернет-зона, що не вважається надійної в плані безпеки від зовнішніх атак. Передбачається, що з Інтернет до певних внутрішніх ресурсів компанії звертаються потенційні клієнти, партнери з інших компаній або постачальники Інтернет-послуг. DMZ (демілітаризована зона) - це область, де небезпечна зона Інтернет перетинається із захищеною внутрішньою мережею. Зовнішня безпека зони DMZ забезпечується роботою міжмережових екранів (firewall) і фільтруючих маршрутизаторів. Такі додатки, як загальнодоступні web-сервери й шлюзи електронної пошти встановлюються саме в зоні DMZ. У зоні Інтранет перебувають внутрішні сервера, а також сервера додатків і баз даних. У цій зоні циркулює внутрішня корпоративна інформація, що повинна бути надійно захищена від несанкціонованого доступу.

Для контролю демілітаризованої зони рекомендується використати міжмережове екранування, використовуючи його як для контролю на границі Інтернет і DMZ, так і на границі DMZ і Інтранет. У цьому випадку Web-сервера, що перебувають у демілітаризованій зоні мають потребу в додатковому захисті, що забезпечує операційна система підвищеної надійності Praesidium VirtualVault для Unix або Praesidium WebEnforcer для NT. Для підвищення безпеки транзакцій і контролю доступу до Web-серверів можна використати Praesidium Authorization Server - сервер, призначений для централізованої перевірки повноважень користувача на запитуваний ресурс.

Платформа для web-серверів VirtualVault VirtualVault - це платформа для web-серверів, що дозволяє захистити критично важливі Інтернет-додатки за рахунок значного скорочення кількості уязвимостей, якими можуть скористатися зловмисники (Рис. 3). VirtualVault включає высоконадежную операційну систему, web-сервер (наприклад, Netscape NES, Apache), а також розділену на зони робітниче середовище, що захищає операційну систему, web-сервер, web-сторінки й тексти інтерфейсних програм, що працюють на платформі web-серверів. VirtualVault також здійснює моніторинг і створює звіти про всі спроби зміни системних файлів або файлів додатків. При розробці системи VirtualVault ураховувалися три базових принципи: мінімалізм; гранично твердий контроль; безперервний моніторинг. Ця операційна система надає тільки ті сервіси, які потрібні для конкретного додатка, при цьому відсутній привілейований користувач, що володіє необмеженими повноваженнями, або адміністратор, а виконання кожного процесу дозволяється тільки при наявності необхідного мінімального набору прав доступу (і тільки на той короткий час, коли це дійсно потрібно). Всі взаємодії між web-сервером, операційною системою й інтерфейсними додатками відбуваються на рівні процесів і контролюються спеціальним механізмом, що створює роздільні віртуальні робітничі середовища для підвищення безпеки й надійності роботи системи. Аналогічним образом обмежується доступ до web-сторінок, системним файлам і файлам додатків. Нижче представлений короткий список основних переваг операційної системи Virtual Vault: Web-сервер конфігурується таким чином, що незахищених місць стає значно менше, ніж у ПО, установленого в режимі за замовчуванням. ПО інсталюється в зовнішній зоні для того, щоб успішні атаки на web-сервер обмежувалися тільки цією областю. Таким чином, внутрішня зона й внутрішні ресурси виявляються надійно захищеними від атак.

В операційній системі VirtualVault (VVOS) немає привілейованого користувача (root user), що міг би використатися зловмисниками або їхніми програмами для атаки на внутрішні ресурси (навпроти, в VirtualVault використається принцип найменшого рівня привілеїв). VVOS розбиває платформу на незалежні підзони, що дозволяє захистити web-сторінки й тексти интерфейсных додатків ОС від атак навіть у тому випадку, якщо частина з них уже досягла свого результату. При використанні такої архітектури додатків ОС VirtualVault перед виконанням додатка проводить перевірку його тексту й запускає на виконання тільки в тому випадку, якщо він не був змінений. Якщо ж у тексті додатка виявлені зміни, виконувані файли можуть бути повернуті у вихідний, незмінений стан, після чого буде створений файл журналу контролю подій і ОС продовжить виконання інших додатків.

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

Сегментування даних створює надійну "стіну" між Інтранет-додатками й користувальницьким інтерфейсом, що обслуговує клієнтів Інтернет. Спочатку розроблена для захисту секретної інформації технологія сегментування була адаптована в VirtualVault для рішення проблеми безпеки в комерційних Інтернет-проектах. Сегментування даних має на увазі класифікацію всіх файлів і програм на сервері по наступних категоріях: Внутрішні (наприклад, бази даних, програми CGI, Java, сервери проміжного ПО); Наружні (наприклад, web-сервер, статичні web-сторінки). ОС VirtualVault розмежовує доступ між цими категоріями. Щоб програма з однієї області одержала доступ в іншу область, вона повинна мати відповідні привілеї. Всі комунікації між Внутрішньою й Зовнішньою областями контролюються за допомогою технології захищених шлюзів VirtualVault. Захищений шлюз захищає додатки, віднесені до категорії ВНУТРІШНІХ, від зловмисних атак або помилок, які могли б при відсутності такого захисту завдати шкоди внутрішнім додаткам. Всі системні додатки зберігаються в системній області з метою збереження їхньої цілісності. Такий поділ захищає web-сторінки від проникнення зловмисників, що вишукують слабкі місця в захисті або конфігурації. Захищені web-сторінки не можуть бути переписані або піддані атаці з метою приміщення непристойних і пропагандистських матеріалів.

4.2 Керування піковими навантаженнями

Програма HP Web Qo додає до основної функціональності VirtualVault досить важливу функцію керування піковими навантаженнями. Ця функція, що безпосередньо впливає на якість послуг, запобігає перевантаженню сервера, мінімізуючи вплив несподіваних сплесків числа запитів і максимізуючи обсяг завершених транзакцій. Керування піковими навантаженнями гарантує, що кожний клієнт, що перебуває в системі, буде обслужений. Нові користувачі не одержують доступу до web-сайту, якщо вони не зможуть завершити свої транзакції відповідним чином. Маючи у своєму розпорядженні інструмент керування піковими навантаженнями, можливо настроїти систему на роботу в одному з наступних режимів:перенаправлення нових запитів в іншу систему, що має необхідні резерви продуктивності; затримка виконання нових завдань на деякий проміжок часу, поки не будуть завершені поточні сеанси; відхилення нових запитів в умовах екстремального навантаження.Результатом такого керування є загальне поліпшення функціонування сайту й одержання конкурентних переваг за рахунок забезпечення більше високої якості послуг. Захищена віртуальна Java-машина За допомогою захищеної віртуальної Java-машини (JVM), що працює у ВНУТРІШНІЙ області виконання додатків, VirtualVault може захистити Java сервер, а також CGI Java-додатка.VirtualVault переносить крос-платформене середовище виконання Java, що є галузевим стандартом, на безпечну платформу виконання додатків. У випадку традиційного web-сервера JVM була б розміщена в тій же області виконання, що й сам web-сервер, тобто в області досяжної із зовнішньої мережі, що піддавало б JVM і Java додатка тієї ж небезпеки, який піддається web-сервер.

Навпроти, надійна web-серверна платформа VirtualVault поміщає JVM і Java відгороджена захищеним шлюзом і недоступна ззовні. Тим самим досягається гарантія того, що прямий доступ до JVM і сервлетам Java у принципі виключений, і ці програми надійно захищені від зовнішніх атак і яких-небудь змін. VirtualVault підтримує JDK CI.17.01 і JSDK 2.0.

4.2.1 Адміністрування системи безпеки

VirtualVault використає інтерфейс популярного web-браузера Netscape Navigator для рішення завдань адміністрування, допускаючи вилучений доступ з Інтранет. Адміністративні завдання можуть вирішуватися після короткого навчання, а онлайнова довідка й гіпертекстова (HTML) документація завжди є під рукою. Більшу допомогу адміністраторам роблять передбачені в системі сеанси аудита з аварійною сигналізацією, під час яких проводяться перевірки всіх ключових елементів, пов'язаних з безпекою системи. Програми, що не мають відповідних повноважень, не можуть одержати доступ до аудиторських звітів. Крім того, всі параметри аудиторських сеансів і аварійної сигналізації VirtualVault можуть бути сконфигурированы для роботи із продуктом OpenView.

Безпека забезпечується завдяки контролю доступу до web-об'єктів, можливості завдання різних рівнів доступу для різних web-об'єктів (наприклад: web-сторінки, ASP, Java-додатка, CGI-сценариии й т.д.). У системі DomainGuard виробляється реплікація даних про політиків по декількох web-серверах для підтримки балансування навантаження й подолання збоїв і одноразова реєстрація користувачів в web-середовищі. Завдяки цій можливості користувачі можуть переходити від одного додатка до іншому, не вводячи щораз пароль, а зареєструвавшись у системі тільки один раз.

4.2.2 Захищеність WEB-серверу Apache

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

Останнім часом зафіксовані непоодинокі випадки масованих атак порушників на АІС зі сторони Інтернету, причому досить часто об'єктом атак був WEB-сервер. Наприклад, за даними Міністерства Оборони США, у 2002 році було зафіксовано 200 атак, мета яких отримання контролю над військовими серверами [1]. Як правило, наслідками більшості успішних атак на WEBсервер ставало унеможливлення санкціонованого доступу, порушення цілісності або створення неконтрольованого поширення інформації АІС. Таким чином у багатьох випадках успішна атака на WEB-сервер може призвести не тільки до загрози функціонування WEB-сайту, але й до значного зменшення ефективності функціонування всієї АІС. Цим визначається актуальність загальної проблеми даної статті дослідження захищеності WEB серверу, а також її зв'язок з глобальною науково-практичною задачею забезпечення інформаційної безпеки АІС.

Для формалізації задачі оцінювання ефективності системи захисту інформаційної системи в [2] сформований наступний методичний підхід. Пропонується розглядати систему захисту у вигляді багаторівневої ієрархії І_р, де р - кількість рівнів ієрархії. Для інформаційних підсистем на кожному р-му рівні ієрархії вибирається множина об'єктів захисту М_кр, де к номер об'єкта на р-му рівні ієрархії. За допомогою експертного оцінювання для кожного М_кр об'єкта формується вектор загроз V_skp, де s - номер загрози для к-го об'єкта на р-му рівні ієрархії.

Зниження ефективності функціонування ІС на кожному р-му рівні E_p визначається складним впливом реально діючих загроз на об'єкти р-го рівня:

E_p(t)=F{M_kp,V_skp,t}, (1)

де F{*} - функціонал, що описує вплив реально діючих загроз V_skp на множину об'єктів M_kp в підсистемі р-го рівня; t - часова характеристика.

При цьому вважається, що відновлення ефективності підсистеми р-го рівня можливо лише завдяки проведенню адекватного рівню інтегральної загрози комплексу заходів безпеки Z_jkp, де j - номер заходу безпеки Z стосовно к-го об'єкта підсистеми р-го рівня. Пропонується поставити в залежність кількісну оцінку рівня інтегральної загрози ІС (U) від зниження ефективності АІС (E) в цих умовах. Таким чином, враховуючи (1), у формалізованому виді рівень інтегральної загрози АІС на момент t можна оцінити функціоналом (2) з урахуванням обмежень (3):

U(t)= F{M_kp,V_skp,t}; (2)

0U(t)1, (3)

де U(t)=0 - означає повну відсутність загрози для АІС, а U(t)=1 -вивід з ладу АІС (ефективність АІС дорівнює 0).

Оцінку рівня загрози деякому к-му об'єкту АІС рекомендується здійснювати по сукупності окремих показників U_kn для відповідного об'єкта. Кожний n-й показник відображає події, пов'язані із зростанням загрози функціонування підсистеми АІС р-го рівня, яка розглядається. Розрахунок (2) рекомендується проводити шляхом часткових розрахунків U(t) у фіксовані моменти часу t на основі використання методу аналізу ієрархій, а потім по окремих точках встановити функціональну залежність, яку можна використовувати у подальшому для прогнозування зміни рівня інтегральної загрози з плином часу. Також у [2] відзначено, що розв'язання задач керування безпекою інформаційної системи на сьогодні формалізоване недостатньо та досить часто базується на методах експертного оцінювання, проб та помилок, що вносить в розрахунки елементи суб'єктивізму і супроводжується досить великими похибками. Запропонований методичний підхід оцінки ефективності захисту АІС є досить досконалим та універсальним, але потребує уточнення та деталізації, як це відзначається і його авторами при оцінці ефективності захисту конкретної АІС, а в нашому випадку WEBсерверу. Також відомі нормативні вимоги до системи захисту WEBсерверів від несанкціонованого доступу (НСД) [3]. Це дозволяє з урахуванням нормативних вимог на базі методики (1-3) провести оцінку ефективності захисту найбільш розповсюджених WEBсерверів від НСД. Зазначимо, що методики визначення такої оцінки в доступній нам літературі не знайдено.

Крім того, для деталізації ефективності захисту WEBсерверу можливо використати результати [4] в якій проведено дослідження захисту WEBсайтів корпоративних інформаційних систем від атак на відмову. Між іншим, в цій статті відзначено, що однією з найбільш небезпечних є атака на відмову WEB-сайту з санкціонованим використанням HTML-файлів та серверних сценаріїв PHP. Очікуваним результатом такої атаки є блокування доступу до сторінок сайту в наслідок вичерпання обчислювальних ресурсів сервера сайту. В даному випадку під поняттям обчислювальних ресурсів сервера розуміються ресурси WEB-сервера, операційної системи комп'ютерної мережі, комп'ютера та каналів зв'язку, що обслуговують сайт. Також в [4] показано, що типова атака на відмову корпоративного WEB-сайту проводиться зловмисником в умовах обмеження обчислювальних потужностей та тривалості. Крім цього очікувані умови атаки слід обмежити кваліфікованим адмініструванням сайту та відсутністю помилок в його програмному та апаратному забезпеченні. Зроблено припущення, що пропускна спроможність каналу зв'язку сайту набагато вища, ніж у зловмисника. При виконанні вказаних обмежень основною причиною блокування ресурсів сайту при атаці на відмову може стати тільки вичерпання потужності центрального процесора комп'ютера, що обслуговує сайт. При цьому обчислювальних потужностей комп'ютера зловмисника призводить до втрати потужностей комп'ютером, що обслуговує функціонування сайту. За цієї причини пропонується технічну ефективність атаки на відмову поставити у відповідність з кореляцією між цими потужностями. Витрату обчислювальних потужностей пропонується визначати:

для зловмисника за допомогою показників навантаженням центрального процесора при реалізації атаки та тривалості виконання атаки для зловмисника;

для комп'ютера, що обслуговує сайт, за допомогою тривалості роботи з 100% навантаженням центрального процесора. При цьому доступ до сторінок сайту гарантовано блокується.

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

. (4)

Під ефективністю блокування розуміємо відношення тривалості 100% навантаження процесора комп'ютера, що обслуговує функціонування сайту, до тривалості виконання атаки:

. (5)

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

Важливим результатом наведеної роботи є кількісні та якісні показники ефективності захисту WEBсерверу Apa-che від атак на відмову. Але для повноти результатів необхідно провести порівняння аналогічних показників ефективності захисту для різних типів WEBсерверів, наприклад для Apache та IIS.

Крім того, проведений аналіз виявив деяку аморфність термінів, що використовуються в науковій літературі, присвяченій захисту інформації в мережі Інтернету. Надалі будемо використовувати терміни, визначені в відповідній вітчизняній нормативній документації [3,5,6].

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

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

Порівняння захищеності WEBсерверів Apache та IIS від атак на відмову із санкціонованим використанням

HTML-файлів та серверних сценаріїв PHP проведено не в повному обсязі.

4.3 Формулювання цілей статті (постановка завдання)

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

Порівняння можливостей типових засобів захисту WEBсерверів Apache та IIS від атак на відмову із санкціонованим використанням серверних сценаріїв.

4.3.1 Виклад основного матеріалу дослідження з повним обґрунтуванням отриманих наукових результатів

Наведемо терміни найбільш важливі для даної статті. WEBсторінка (WEBсайт) це мережевий інформаційний ресурс, наданий користувачеві у вигляді.

HTMLдокумента з унікальною адресою у мережі. Сервер (server) об'єкт комп'ютерної системи (програмний або програмно-апаратний засіб), що надає послуги іншим об'єктам за їх запитами. WEBсервер обслуговує запити користувачів (клієнтів) згідно з протоколом HTTP (Hyper Text Transfer Protocol), забезпечує актуалізацію, збереження інформації WEBсторінки, зв'язок з іншими серверами.

Використавши методику (1-3), інтегральну оцінку ефективності захисту WEBсерверів (Z_w(t)) можна провести наступним чином:

Z_w(t)=F{Z_wi,V_i,t}, (8)

де V_i загроза за номером і; Z_wi ефективність заходу безпеки від загрози V_i; t - часова характеристика.

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

Z_w=F{Z_wi,V_i}. (9)

Крім того, в першому наближені можна прийняти, що величина Z_wi детермінована і може набувати тільки два значення: 0 захід неефективний та 1 захід ліквідує загрозу. Розглянемо випадок визначення інтегральної оцінки захисту WEBсерверів від НСД. У цьому випадку відомий перелік нормативних заходів безпеки, що дозволяє переписати функціонал (9) у наступному вигляді:

, (10)

де i номер заходу безпеки; N нормативна кількість заходів безпеки.

Очевидно, що мінімальна величина Z_w=0, а максимальна Z_w=N. При Z_w=0 захист абсолютно неефективний з точки зору відповідності нормативам. При Z_w=N захист повністю відповідає нормативним заходам безпеки. Крім визначення кількісної оцінки ефективності захисту використання рівняння (10) дозволяє співставити захищеність WEB серверів різних типів. Відзначимо, що кількість існуючих на сьогодні WEB серверів досить велика, але найбільш розповсюдженими є Apache та WEB сервери компанії Microsoft. Так, відповідно до матеріалів [7,8], кількість WEB сайтів, що забезпечуються Apache становить 55% від загальної кількості. WEB сервери компанії Microsoft забезпечують біля 25% WEBсайтів. Розповсюдженість Apache пояснюється в першу чергу його безкоштовністю та відкритістю програмного коду. Останнє означає, що можна настроїти WEBсервер для конкретних завдань, додати або знищити певні модулі, а також виправити дефекти програми. Ще одною важливою перевагою є мультиплатформеність Apache. Він використовується на серверах Unixсистем, в системах Macintosh, на серверах Windows. Настроювання Apache реалізоване за допомогою конфігураційних файлів, в які вносяться директиви для керування його функціональними можливостями. Великий обсяг можливих директив робить настроювання цього WEBсервера доволі гнучким та надає адміністратору широкі можливості в сфері керування системою захисту. До загальновідомих недоліків Apache відносять:

відсутність завершеного та досконалого графічного інтерфейсу, що значно ускладнює роботу адміністратора WEBсервера;

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

Для WEBсерверів компанії Microsoft вказані недоліки не характерні. Ці WEBсервери є складовими компонентами таких операційних систем, як Windows NT, Windows 2000, Windows XP [7]. Найбільш популярні сучасні версії WEBсерверу компанії Microsoft входять до складу Internet Information Services (IIS) набору базових служб Інтернету. Крім WEBсерверу до складу IIS включені FTPсервер, SMTPсервер, NNTP сервер та ряд додаткових служб. Служби IIS об'єднані за допомогою стандартного графічного інтерфейсу адміністрування та спільних методів керування, що є беззаперечною перевагою, а, крім того, вони стандартизовані для Windows-методів керування, що робить процес адміністрування відносно простим.

У загальному випадку WEB сервер повинен забезпечувати реалізацію вимог із захисту цілісності та доступності розміщеної на WEBсторінці загальнодоступної інформації, а також конфіденційності та цілісності технологічної інформації WEB-сторінки. Надалі розглянемо тільки ті вимоги до системи захисту, реалізувати які можна допомогою вдосконалення програмних засобів та методики застосування цих засобів. До методики застосування програмних засобів, крім іншого, слід віднести повноту та досконалість відповідної документації. З врахуванням цих зауважень на основі [2] проведена структуризація типових вимог до системи захисту WEBсерверу від НСД (рис.1). Відзначимо, що, крім вимог "надійність середовища розробки" та "відкритість програмного коду", інші типові вимоги наведені в вітчизняному державному стандарті [3]. Включення вимог "надійність середовища розробки" та "відкритість програмного коду" в перелік типових здійснене на основі висновків [4]. Назви інших вимог відповідають нормативним. Для деяких вимог на рис. 1 наведені пояснення їх змісту. Принциповим моментом є структуризація вимог відповідно до життєвого циклу WEB серверу. Проведемо аналіз відповідності систем захисту WEBсерверів Apache та IIS цим вимогам. Відзначимо, що надалі заходи захисту Apache будемо позначати Z^a_wn, а IIS Zⁱ_wn, де n номер заходу.

1. Програмне забезпечення Apa-che і IIS побудоване за модульним принципом. Таким чином, Z^a_w1 = Zⁱ_w1 =1.

2. Для відповідності цим вимогам мають бути визначені всі стадії та етапи життєвого циклу WEBсерверу, а для кожної стадії та етапу - перелік та обсяги необхідних робіт і порядок їх виконання. Всі етапи робіт повинні бути задокументовані відповідно до правил встановлених вітчизняними державними стандартами. Відзначимо, що наявність цієї документації є загальноприйнятою вимогою при проектуванні захищених інформаційних систем. Хоча в звичайний супроводжуючий комплект документів Apache та IIS дана документація не входить, але її можна отримати при офіційному зверненні до компаній розробників. Тому, виходячи із фактичного стану речей, вважаємо, що Z^a_w2 = Zⁱ_w2 = 1.

3. Хоча форма специфікацій на функціональні послуги безпеки Apache та IIS дещо не відповідає вітчизняним стандартам, але їх досконалість підтверджена практичним досвідом. Тому Z^a_w3=Zⁱ_w3 = 1.

4. Для відповідності цим вимогам документація на систему захисту повинна містити опис послуг безпеки, що в ній реалізуються, а також настанови для різних категорій користувачів. Для обох WEBсерверів вказана документація, що доступна та досить детальна. Тому Z^a_w4 = Zⁱ_w4= 1.

5. Практичний досвід показує, що система безпеки Apache та IIS пройшла багаторазове та жорстке тестування, хоча програма і методика тестувань не входять до звичайного комплекту супроводжуючої документації цих WEBсерверів, що вимагається [3]. Проте відповідна доукомплектація, на наш погляд, не викликатиме особливих труднощів при офіційному зверненні до компаній розробників. Тому, виходячи із фактичного стану речей, Z^a_w5 = Zⁱ_w5 = 1.

6. Надійність середовища розробки означає надійність мови програмування, що була застосована для реалізації WEBсерверу. Apache та IIS реалізовані на досить апробованій та надійній мові програмування C++. Таким чином, Z^a_w6 = Zⁱ_w6= 1.

7. Вимозі відкритості програмного коду відповідає тільки Apache. Z^a_w7 = 1, Zⁱ_w7= 0.

8. Як Apache, так і IIS дозволяють здійснювати розмежування прав користувачів на перегляд WEBсторінок на підставі атрибутів доступу користувача і захищеного об'єкта. Тому Z^a_w8= Zⁱ_w8= 1.

9. Як Apache так і IIS дозволяють здійснювати розмежування прав користувачів на модифікацію WEBсторінок на підставі атрибутів доступу користувача і захищеного об'єкта. Тому Z^a_w9= Zⁱ_w9= 1.

10. Обидва WEBсервери дозволяють забезпечити захист інформації від несанкціонованого ознайомлення під час їх експорту/імпорту через незахищене середовище. Для цього використовуються комунікаційний протокол SSL, що використовує метод шифрування з відкритим ключем. В Apache протокол SSL реалізований декількома способами, серед яких Apache SSL та різноманітні комерційні варіанти. Таким чином, Z^a_w10 = Zⁱ_w10 = 1.

11. Використання протоколу SSL дозволяє системам захисту Apache і IIS забезпечити надійний контроль за цілісністю інформації в повідомленнях, які передаються, а також здатність виявляти факти їх несанкціонованого видалення або дублювання. Тому Z^a_w11 = Zⁱ_w11 = 1.

12. Відкат забезпечує можливість відмінити окрему операцію або послідовність операцій і повернути захищений об'єкт після внесення до нього змін до попереднього наперед визначеного стану. Для забезпечення відкату до складу WEBсерверу повинні входити автоматизовані засоби, які дозволяють адміністратору безпеки відмінити певний набір операцій, виконаних над захищеним об'єктом WEB-сторінки за певний проміжок часу. Факт використання послуги має реєструватись у системному журналі. Програмне забезпечення Apache та IIS дозволяє забезпечити відкат, тому Z^a_w12 = Zⁱ_w12 = 1.



13. Визначення ліміту на обчислювальні ресурси означає можливість обмеження щодо використання окремим користувачем та/або процесом обсягів обчислювальних ресурсів серверу. Спроби користувачів перевищити встановлені обмеження на використання ресурсів повинні реєструватися в системному журналі. Обидва WEBсервери дозволяють визначити кількість обчислювальних потоків, розмір буфера пам'яті, що використовується протоколом TCP/IP, розмір тіла запиту HTTP, розмір черги мережевих з'єднань. Тому Z^a_w13 = Zⁱ_w13 = 1.

14. Відповідність вимозі відновлення після збоїв означає визначення множини типів відмов WEB-серверу і переривань обслуговування, після яких можливе повернення у відомий захищений стан без порушення політики безпеки. Аналіз документації обох WEB-серверів та практичний досвід показує, що повернення у відомий захищений стан після збоїв відбувається без порушення політики безпеки. Тому Z^a_w14 = Zⁱ_w14 = 1.

15. Самотестування повинно дозволяти WEB-серверу перевірити і на підставі цього гарантувати правильність функціонування і цілісність певної множини функцій захисту. Аналіз документації та функціональних можливостей Apache та IIS показав відсутність в них можливості самотестування. По цій причині Z^a_w15 = Zⁱ_w15 = 0.

Підсумовуючи проведений аналіз та використавши (10), розрахуємо інтегральну оцінку системи захисту Apache (Z^a_w) та IIS (Zⁱ_w). Отже, Z^a_w =14, Zⁱ_w=13. Відзначимо, що відповідно методиці [2] та вітчизняним стандартам [3], для обох WEB-серверів максимально можлива величина інтегральної оцінки дорівнює 15. Порівняння одержаних реальних величин цієї оцінки з максимально можливою вказує на досить високу захищеність як Apache, так і IIS від НСД. Крім того, результати порівняння вказують на дещо кращу захищеність Apache завдяки наявності відкритого програмного коду, хоча це і не вимагається у вітчизняних стандартах. Відзначимо, що наявність відкритого програмного коду, на наш погляд, є досить важливою вимогою до системи захисту WEB-серверу. Наприклад, тому, що унеможливлює створення різноманітних програмних пасток розробниками WEB-серверу.

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

Для порівняння можливостей типових засобів захисту WEBсерверів Apache та IIS від описаних атак на відмову були проведені числові експерименти. Як доведено в [5], найбільш небезпечною є атака з використанням тільки відкриття файлів по протоколу HTTP. Тому для визначення ефективності захисту план експерименту передбачав тільки відкриття HTML- та PHP-файлів. Для здійснення атаки засобами Microsoft VC++.NET було розроблено спеціальну прикладну програму. Ефективність та надійність функціонування програми була забезпечена за допомогою бібліотеки для роботи з Інтернет afxinet. Основними етапами роботи програми є відкриття сесії, багаторазовий доступ до файлу по протоколу HTTP в циклі з визначеною кількістю ітерацій, закриття сесії та обчислення терміну виконання циклу. В якості WEB- серверу використано Apache 1.3 та IIS 5.0, які працювали на комп'ютері Intel Pentium 3 ( тактова частота 600 МГц, обсяг оперативної пам'яті 256 Мб) під керуванням операційної системи Microsoft Windows 2000 Server. Атака здійснювалась з використанням одного комп'ютера з аналогічними характеристиками під керуванням операційної системи Microsoft Windows 2000 Professional. Експеримент проводився в локальній мережі з топологією "зірка" з пропускною здатністю 100 Мбіт/с. Відзначимо, що WEB-сервер знаходився на комп'ютері сервері домена. Під час проведення експериментів в мережі працювали тільки комп'ютери, які брали участь у експерименті. Реєстрація параметрів використання системних ресурсів комп'ютерів здійснювалась програмно (термін виконання запитів) та за допомогою Windows Task Manager (навантаження процесора). Кожен експеримент повторювався тричі за тих самих вихідних даних. При цьому в різних експериментах величини зареєстрованих параметрів відрізнялись на 3-5%. Крім того, були розраховані середньоарифметичні величини зареєстрованих параметрів. Таким чином, похибка отриманих результатів знаходиться в межах 5%, що вважається прийнятною при інженерних розрахунках.

Для обох WEB-серверів для повного блокування сайту достатньо здійснити близько 1000 циклічних процедур відкриття/закриття для HTML-файлів та 100 аналогічних процедур для PHP-файлів.

Аналіз тривалості виконання Web-сервером клієнтських запитів вказує на різке зростання терміну виконання запиту сервером при зверненні до PHP-файлів відносно HTML-файлів. При здійсненні атаки шляхом відкриття PHP-файлів термін блокування сервера в 19 - 20 разів триваліший, ніж при атаці шляхом відкриття HTML- файлів. Можна відзначити, що для обох WEB-серверів термін виконання запитів до PHP- файлів приблизно однаковий. У той же час термін виконання запитів до HTML-файлів IIS більше, ніж в 2 рази менший ніж в Apache.

Для порівняння захищеності Apache та IIS згідно (4 - 7) було розраховано показники ефективності захисту PHP та HTML-файлів. Результати розрахунків наведеані в табл.3.

Аналіз даних табл.3 показує, що для HTML-файлів ефективна потужність захисту IIS приблизно в 1.2 рази вища, ніж у Apache, а показник ефективності захисту від блокування IIS вищий більш ніж у 2 рази від аналогічного показника Apache. При цьому показники ефективності захисту при атаці на PHP-файли для обох WEB-серверів приблизно однакові.

Відзначимо, що зміна конфігурації та характеристик апаратно-програмного забезпечення комп'ютерної мережі може досить відчутно вплинути на кількісні показники результатів атаки (термін виконання запиту, навантаження процесора). Проте вплив такої зміни на показники ефективності захисту WEB-серверів, що носять відносний характер, не такий відчутний [4]. Тому якісна оцінка ефективності захисту Web-серверів, а також результат порівняння захищеності Apache та IIS відповідає дійсності.

4.3.2 Висновки з даного дослідження і перспективи подальших розвідок у цьому напрямку

Визначена інтегральна оцінка ефективності захисту від НСД WEB-серверів Apache та IIS із урахуванням відповідної вітчизняної нормативної бази: Apache Z_aw=14, IIS Z_iw=13. При цьому максимально допустима величина оцінки Z_w=15. Таким чином, ефективність захисту від НСД як Apache, так і IIS досить висока. Важливим напрямком підвищення рівня захисту від НСД для Apache і IIS є введення в них функцій самотестування та доукомплектація супроводжуючої документації відповідно вітчизняних державних стандартів.

Проведено детальне порівняння захищеності WEB-серверів Apache та IIS від атак на відмову з санкціонованим використанням HTML-сторінок та серверних сценаріїв PHP.

Доведено, що захищеність IIS від атак на відмову із санкціонованим

використанням HTML-сторінок суттєво вища Apache.

Доведено, що захищеність IIS та Apache від атак на відмову із санкціонованим використанням серверних сценаріїв PHP приблизно однакова.

Перспективи подальших розвідок у даному напрямі полягають в досліджені захищеності WEBсерверів Apache та IIS від атак на відмову із санкціонованим використанням серверних сценаріїв, що створені за допомогою загальнопоширених технологій. До таких слід віднести Java, ActiveX, SSI, ASP, C#. Результатом досліджень може стати універсальна система захисту WEBсерверів від атак на відмову. Крім того, цікавим напрямом дослідження в галузі захисту WEB серверів від НСД з метою вдосконалення вітчизняної нормативної бази.

5. Атестація робочого місця за умовами праці

В зв'язку з постановою Кабінету Міністрів України “Про Порядок проведення атестації робочих місць за умовами праці” від 1 серпня 1992 року № 442. проведемо атестацію умов робочого місця за яких виконувався проект.

Під час аналізу умов праці оцінюються: санітарно-гігієнічні умови праці: характеристика приміщення та робочого місця; мікроклімат приміщення; акустичні характеристики приміщення; штучне та природне освітлення. Електробезпека.

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

5.1 Аналіз умов праці

Проект розроблявся в адміністративній будівлі в м Києві за адресою вул. Комінтерну 27 кімната 103 (мал.1)

(мал.1)

У робочому кабінеті працює 4 чоловіки. Кабінет також слугує приміщенням де відбувається прийняття персоналу компанії з короткими консультаціями. Роботи, що виконуються програмістом наступні: розробка програмного забезпечення (25 % всього часу), оформлення документації(50 % всього часу), робота з створеною системою(25 % всього часу). Усі види робіт проводяться з застосуванням персональних комп'ютерів оснащених 17 дюймовими ЕЛТ моніторами, також за ноутбуком оснащеним 15 дюймовою матрицею.

Робочий кабінет знаходиться на цокольному (що суперечить державним санітарним правилам і нормам) поверсі 5-и поверхового будинку.

Параметри кімнати наступні:

Довжина 6.5 м

Ширина 5 м

Висота 3.

Площа кабінету складає 32.5 м². А об'єм 97.5 м³. Таким чином на одного робочого припадає: площі - 6.5 м² і об'єму 19.5 м³, що відповідає державним санітарним правилам і нормам 3.3.2.007-98(6м² та 19.5 м³ ). На малюнку нижче приведений план приміщення з місцезнаходженням робочих місць (мал.2).

(мал.2)

Тип обладнання, що працює в кабінеті:

4 комп'ютери.

Celeron 1,8 Ггц, монітор Samsung 753MB (1024х768х85 Гц).

Celeron 1.7 Ггц, монітор Samsung 757 DFX (1024х768х100 Гц).

2 Pentium IV 2 Гц, монітор Samsung 710N (1024х768х85 Гц).

Монітори всіх комп'ютерів відповідають стандарту безпеки TCO-99

БФП (багатофункціональний пристрій - ксерокс, принтер, сканер)

2 принтери

5 Джерел освітлення - лампи денного освітлення.

5.1.1 Розрахунок повітряного середовища

У таблиці нижче приведені норми температури, відносної вологості та швидкості руху повітря на робочих місцях відповідно до ДСанПіН 3.3.2.007-98, що встановлюють норми мікроклімату для приміщень даної категорії.

Параметри мікроклімату	Період року	Температура 0С	Відносна вологість, %	Швидкість руху повітря
Оптимальні	Холодний	21-24	40-60	0.1
	Теплий	23-25	40-60	0.1
Допустимі	Холодний	21-25	Не більше 75	0.1
	Теплий	22-26	40-60	0.2
Фактичні	Холодний	18**-24	40-50	<0.1
	Теплий	22*-28	45-60	<0.1

* - без кондиціонера ** - без додаткових обігрівачів

В холодну пору року в приміщенні, де працює програміст температура повітря 18-24 0С, що не відповідає значенням допустимої температури повітря по ДСанПіН 3.3.2.007-98 допустима температура повітря знаходиться в дiапазонi вiд 21 до 25 ⁰С (оптимальна становить 21-24 ⁰С). Що може визвати шкідливі наслідки для організму, тому виникає потреба в додатковому встановленні обігрівача.

В теплу пору року в приміщенні, де працює Програміст температура повітря 22-28 ⁰С, що теж не відповідає державним нормам, так як згiдно з нормами допустима температура повітря знаходиться в дiапазонi вiд 20 до 24 0С (оптимальна становить 21-23 0С).Що може мати шкідливий вплив для організму. В холодну пору року в приміщенні, де працює програміст відносна вологість повітря 40-50 %, що становить оптимальну норму.

Згідно з ДСанПіН 3.3.2.007-98:

допустима відносна вологість повітря на постійних робочих місцях в холодну пору року не більша 75 % (оптимальна становить 40-60 %).

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

В холодну пору року в приміщенні, де працює Програміст, швидкість руху повітря 0.1 м/с, що відповідає нормам.

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

У кабінеті вже обладнано кондиціонер Mitsubishi Heavy SRK50HE-S1, потужністю 5,4 кВт врахування необхідної потужності по об'єму повітря, що подається. Для розрахунку потужності необхідної для підтримання оптимальних умов достатньо наявної системи опалення та кондиціонеру.

Розрахуємо необхідну потужність кондиціонеру, за допомогою програми IVIK(мал.3):

(мал.3)

(мал.4)

Необхідна потужність кондиціонера для даного приміщення 4,97 кВт (кондиціонер Mitsubishi Heavy SRK50HE-S1 )

5.1.2 Розрахунок рівня освітлення

Виробниче освітлення роботі, що виконуються в приміщенні відносяться до 2 розряду робіт (характеристика роботи - висока точність):