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

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] сформований наступний методичний підхід. Пропонується розглядати систему захисту у вигляді багаторівневої ієрархії Ір, де р – кількість рівнів ієрархії. Для інформаційних підсистем на кожному р-му рівні ієрархії вибирається множина об’єктів захисту Мкр, де к - номер об’єкта на р-му рівні ієрархії. За допомогою експертного оцінювання для кожного Мкр об’єкта формується вектор загроз Vskp, де s – номер загрози для к-го об’єкта на р-му рівні ієрархії.

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

DEp(t)=F{Mkp,Vskp,t}, (1)

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

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

U(t)= F{Mkp,Vskp,t}; (2)

0ЈU(t)Ј1, (3)

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

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

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

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

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

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

. (4)

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

. (5)

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

Важливим результатом наведеної роботи є кількісні та якісні показники ефективності захисту 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-серверів (Zw(t)) можна провести наступним чином:

Zw(t)=F{Zwi,Vi,t}, (8)

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

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

Zw=F{Zwi,Vi}. (9)

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

, (10)

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

Очевидно, що мінімальна величина Zw=0, а максимальна - Zw=N. При Zw=0 захист абсолютно неефективний з точки зору відповідності нормативам. При Zw=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 будемо позначати Zawn, а IIS - Ziwn, де n - номер заходу.

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

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

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

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

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

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

7. Вимозі відкритості програмного коду відповідає тільки Apache. Zaw7 = 1, Ziw7= 0.

8. Як Apache, так і IIS дозволяють здійснювати розмежування прав користувачів на перегляд WEB-сторінок на підставі атрибутів доступу користувача і захищеного об’єкта. Тому Zaw8= Ziw8= 1.

9. Як Apache так і IIS дозволяють здійснювати розмежування прав користувачів на модифікацію WEB-сторінок на підставі атрибутів доступу користувача і захищеного об’єкта. Тому Zaw9= Ziw9= 1.

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

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

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

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

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

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

Підсумовуючи проведений аналіз та використавши (10), розрахуємо інтегральну оцінку системи захисту Apache (Zaw) та IIS (Ziw). Отже, Zaw =14, Ziw=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 Zaw=14, IIS Ziw=13. При цьому максимально допустима величина оцінки Zw=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 м2. А об’єм 97.5 м3. Таким чином на одного робочого припадає: площі – 6.5 м2 і об’єму 19.5 м3, що відповідає державним санітарним правилам і нормам 3.3.2.007-98(6м2 та 19.5 м3 ). На малюнку нижче приведений план приміщення з місцезнаходженням робочих місць (мал.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, що встановлюють норми мікроклімату для приміщень даної категорії.

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

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

В теплу пору року в приміщенні, де працює Програміст температура повітря 22-28 0С, що теж не відповідає державним нормам, так як зг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 м/с, що теж відповідає державним нормам. Як бачимо у розглядаємому приміщенні норми мікроклімату відповідають визначеним державою