3.5. Конфігурація безпечної директорії web-вмісту

Для конфігурації безпечної директорії web-вмісту необхідно виконати наступні дії:

• Виділити окремий жорсткий диск або логічний розділ для web-вмісту і встановити відповідні піддиректорії виключно для файлів вмісту web-сервера, включаючи графіку, але виключаючи скрипти і інші програми;

• Визначити окрему директорію виключно для всіх зовнішніх по відношенню до ПО web-сервера скриптів або програм, що виконуються як частина вмісту web-сервера (наприклад, CGI, ASP і тому подібне);

• Заборонити виконання скриптів, які не знаходяться під управлінням адміністративних акаунтів. Дана дія виконується створенням доступу і управлінням ним до окремої директорії, яка призначена для авторизованих скриптів;

• Створити групи і користувачів для web-сервера;

• Заборонити використання жорстких і символічних посилань (аналог shortcuts в Windows);

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

• Перевірити політику паролів в організації і встановити відповідні критерії паролів (довжина, складність);

• Використовувати при необхідності файл robots.txt.

3.6. Використання програм перевірки цілісності

Для перевірки цілістності необхідно виконати наступні дії:

• Інсталювати перевірку цілісності для захисту конфігураційних файлів web-сервера;

• Перераховувати контрольні суми при зміні вмісту файлів;

• Зберігати контрольні суми в захищеному від запису носієві;

• Регулярно порівнювати контрольні суми критичних файлів з еталонними значеннями.

4. Безпека програмного середовища

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

Для Web-серверов аналогом процедур, що зберігаються, є програми, обслуговуючі загальний шлюзовий інтерфейс (Common Gateway Interface - CGI). CGI-процедуры розташовуються на серверах і зазвичай використовуються для динамічного породження HTML-документов. Політика безпеки організації і процедурні заходи повинні визначати, хто має право поміщати на сервер CGI-процедуры. Жорсткий контроль тут необхідний, оскільки виконання сервером некоректної програми може привести до скільки завгодно тяжких наслідків. Розумна міра технічного характеру полягає в мінімізації привілеїв користувача, від імені якого виконується Web-сервер.

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

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

• доступності (програма може поглинути всі наявні ресурси);

• цілісності (програма може видалити або пошкодити дані);

• конфіденційності (програма може прочитати дані і передати їх по мережі).

Проблему ненадійних програм усвідомлювали давно, але, мабуть, тільки в рамках системи програмування Java вперше запропонована цілісна концепція її рішення.

Java пропонує три оборонні рубежі:

• надійність мови;

• контроль при отриманні програм;

• контроль при виконанні програм.

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

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

Цікавий підхід пропонують фахівці компанії Sun Microsystems для забезпечення безпечного виконання командних файлів. Мова йде про середовище Safe-Tcl (Tool Comman Language, інструментальна командна мова). Sun запропонувала так звану осередкову модель інтерпретації командних файлів. Існує головний інтерпретатор, якому доступні всі можливості мови. Якщо в процесі роботи програми необхідно виконати сумнівний командний файл, породжується підлеглий командний інтерпретатор, що володіє обмеженою функціональністю (наприклад, з нього можуть бути видалені засоби роботи з файлами і мережеві можливості). В результаті потенційні небезпечні програми виявляються поміщеними в осередки, що захищають призначені для користувача системи від ворожих дій. Для виконання дій, які вважаються привілейованими, підлеглий інтерпретатор може поводитися із запитами до головного. Тут, очевидно, є видимою аналогія з розділенням адресних просторів операційної системи і призначених для користувача процесів і використанням останніми системних викликів. Подібна модель вже близько 30 років є стандартною для ОС.

Захист Web-серверів

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

У Web-серверах об'єктами доступу виступають універсальні локатори ресурсів (URL - Uniform (Universal) Resource Locator). За цими локаторами може стояти різна суть - HTML-файли, CGI-процедури і тому подібне

Як правило, суб'єкти доступу ідентифікуються по IP-адресам і/або іменах комп'ютерів і областей управління. Крім того, може використовуватися парольна аутентифікація користувачів або складніші схеми, засновані на криптографічних технологіях (див. наступний розділ).

У більшості Web-серверів права розмежовуються з точністю до каталогів (директорій) із застосуванням довільного управління доступом. Можуть надаватися права на читання HTML-файлів, виконання CGI-процедур і так далі.

Для раннього виявлення спроб нелегального проникнення в Web-сервер важливий регулярний аналіз реєстраційної інформації.

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

Ще один загальний принцип полягає в тому, щоб мінімізувати об'єм інформації про сервер, яку можуть отримати користувачі. Багато серверів у разі звернення по імені каталога і відсутності файлу index.HTML у нім, видають HTML-варіант змісту каталога. У цьому змісті можуть зустрітися імена файлів з початковими текстами CGI-процедур або з іншою конфіденційною інформацією. Такого роду “додаткові можливості” доцільно відключати, оскільки зайве знання (зловмисника) умножає печалі (власника сервера).