Клиент - сервер

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

ЗМІСТ

1. Аналіз архітектури та інформаційних ресурсів ОІД………………… З
2. Модель ОІД з позицій інформаційної безпеки. Перелік та категоріювати інформацію, яка підлягає захисту в ОІД…………… 7
3. Аналіз інформаційного, фізичного, обчислювального середовища, середовища користувачів та персоналу ОІД………………………... 11
4. Модель загроз ОІД…………………………………………………….. 14
5. Структурна схема КСІБ ОІД………………………………………….. 16
6. Загальна політика безпеки інформації та План захисту…………… 18
7. Перелік детальних вимог до системи захисту ресурсів…………… 21

 

8. Перелік детальних  вимог до підсистем захисту інформаційних  ресурсів ОІД…………………………………………………………… 23
9. Структурна схему захисту інформаційних ресурсів ОІД…………. 27

      Використана література………………………………………………. 40   
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

  1.Аналіз архітектури та інформаційних ресурсів  

Архітектура "клієнт/сервер"

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

1. 1.Модель доступу до віддалених даними (Remote Data Access - RDA);
2. Модель сервера бази даних (Data Base Server - DBS);
3. Модель сервера додатків (Application Server - AS).

RDA- модель

У RDA- моделі (рис. 1) коди компонента подання і прикладного компонента суміщені і виконаються на комп'ютері-клієнті. Останній підтримує як функції введення і відображення даних, так і прикладні функції ("товстий" клієнт).

Рис. 1. RDA- модель.

 

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

       Говорячи  про архітектуру "клієнт / сервер", в більшості випадків мають на увазі саме цю модель.

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

Більшість з них підтримують графічний  інтерфейс користувача в MS Windows, стандарт інтерфейсу ODBC, містять засоби автоматичної генерації коду. Переважна більшість цих засобів розробки на мовах четвертого покоління (включаючи і засоби автоматизації програмування) якраз і створюють коди, у яких змішані прикладні функції та функції подання.

У той  же час RDA-модель має ряд обмежень.

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

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

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

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

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

DBS-модель

У DBS-моделі (рис. 2) процес, що виконується на комп'ютері-клієнті, обмежується функціями подання ("тонкий" клієнт), а прикладні функції реалізовані в збережених процедур (stored procedure), які також називають компільований резидентними процедурами, або процедурами бази даних .

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

Рис. 2. DBS-модель.

DBS- модель реалізована в деяких реляційних СУБД (Ingres, Sybase, Oracle). Її основу складає механізм збережених процедур - засіб програмування ядра СУБД. Процедури зберігаються в словнику бази даних, розділяються між декількома клієнтами і виконуються на тому ж комп'ютері, де функціонує ядро СУБД. Мова, на якому розробляються збережені процедури, представляє собою процедурне розширення мови запитів SQL.

Переваги  DBS-моделі очевидні:

1.Можливість централізованого адміністрування бізнес-функцій, розміщених на сервері.

2.Зниження трафіку в мережі.

3.Можливість поділу процедури між кількома програмами, і економія ресурсів комп'ютера за рахунок використання одного разу створеного плану виконання процедури.

Однак є й недоліки:

  Засоби, які використовуються для написання  збережених процедур, строго кажучи, не є мовами програмування в повному  сенсі слова. Це різноманітні процедурні розширення SQL, не витримують порівняння з образотворчим засобам і функціональними можливостями з мовами третього покоління (С або Pascal) і тим більше четвертого покоління. Вони вбудовані в конкретні СУБД, і, природно, рамки їх використання обмежені.

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

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

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

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

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

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

AS- модель

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

Рис. 3. АS- модель

Основним  елементом прийнятої в AS- моделі три ланковий схеми є сервер програми. У його рамках реалізовано кілька прикладних функцій, кожна з яких оформлена як служба (service) і надає деякі послуги всіма програмами, які бажають і можуть ними скористатися. Серверів додатків може бути кілька, і кожен з них надає певний набір послуг. Будь-яка програма, яка користується ними, розглядається як клієнт додатки (Application Client | AC).

Деталі  реалізації прикладних функцій в  сервері додатків повністю приховані від клієнта програми. АS звертається із запитом до конкретної службі, але не до AS, тобто сервери додатків знеособлені і служать лише свого роду "рамкою" для оформлення служб, що дозволяє ефективно управляти балансом завантаження. Запити, що надходять від АС, шикуються в чергу до AS- процесу, який витягує і передає їх для обробки службі відповідно до пріоритетів.

АS трактується більш широко, ніж компонент подання. Він може підтримувати інтерфейс з кінцевим користувачем (тоді він є компонентом подання), може забезпечувати надходження даних від деяких пристроїв (наприклад, датчиків), може, нарешті, сам по собі бути AS. Останнє дозволяє реалізувати прикладну систему, що містить AS декількох рівнів.

Архітектура такої системи може виглядати  як ядро, оточене концентричними кільцями. Ядро складається з серверів додатків, у яких реалізовані базові прикладні  функції. Кільця символізують набори AS, що є клієнтами по відношенню до серверів нижнього рівня. Число рівнів серверів в AS-моделі, взагалі кажучи, не обмежена.

AS-модель найбільшою мірою відображає сильні сторони технології "клієнт / сервер":

      1. Чітке розмежування логічних компонентів програми.

2. Можливість балансу завантаження між декількома серверами.
3. Значне зниження трафіку між клієнтом і сервером додатків, що дає можливість роботи з повільними лініями зв'язку.
4. Високий рівень захисту даних, оскільки вони є "захованими" за сервісами програми, в які можна вбудувати перевірку повноважень клієнта.
5. Можливість використання в якості клієнтської частини програми стандартного браузера.
6. Спрощення процесу оновлення ПЗ.

 

                                2.Модель "клієнт-сервер" 

      Модель "клієнт-сервер" пов'язана з  принципом відкритих систем. Термін "клієнт-сервер" початково застосовувався в архітектурі ПЗ, яке орієнтувало розподіл процесу виконання за принципом взаємодії 2-х програм, процесів, один з яких у цій моделі називався клієнтом, а інший - сервером. При цьому передбачалося, що один серверний процес може обслуговувати безліч клієнтських процесів.

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

   Тепер всі ПК в мережі мають власними ресурсами і розумно так розподілити  навантаження на них, щоб максимальним чином використовувати їхні ресурси. Основний принцип технології "клієнт - сервер" в БД полягає в розділенні функцій стандартного інтерактивного додатки на 5 груп:

1. Функція введення та відображення даних;
2. Прикладні функції, що визначають основні алгоритми розв'язання задач додатки ;
3. Функції обробки даних усередині програми ;
4. Функції управління інформаційними ресурсами;
5. Службові функції, які грають роль зв'язок між функціями 1-х і 4-х

груп.

Структура типової програми, що працює з БД. 

 

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