3.7Основи синтезу моделей безпеки

3.7.1Методика синтезу моделей безпеки

Нехай задана полiтика безпеки P. Система захисту вважа¹ться хорошою, якщо вона надiйно пiдтриму¹ P, i поганою, якщо вона ненадiйно пiдтриму¹ P. Проте надiйнiсть пiдтримки також необхiдно точно визначити. Тут можна знову звернутися до i¹рархiчно¨ схеми. Нехай полiтика P виражена на мовi M1, формули яко¨ ви-

значаються через послуги U1, ..., Uk.

Методику синтезу моделей безпеки розглянемо на наступному прикладi [9].

Óñi ñóá'¹êòè S системи роздiленi на двi множини S1 i S2, S1 S2 = S, S1 ∩ S2 = Ø. Óñi îá'¹êòè O системи, до яких можна здiйснити доступ, роздiленi на два класи O1 i O2, O1 O2 = O,

O1 ∩ O2 = Ø.

Полiтика безпеки P ¹ тривiальною: суб'¹кт S може мати доступ α R äî îá'¹êòà O òîäi i òiëüêè òîäi, êîëè S Bi, O Oi, i = 1, 2. Для кожного звернення суб'¹кта S на доступ до об'¹кта O система захисту обчислю¹ функцiю належностi

(

1, x A Ix(A) =

0, x / A

äëÿ ñóá'¹êòà i îá'¹êòà: Is(S1), Is(S2), Io(O1), Io(O2). Потiм обчи- слю¹мо логiчний вираз:(Is(S1) Io(O1)) (Is(S2) (Io(O2)).

Якщо одержане значення 1 (iстинно), то доступ дозволений. Якщо 0 (хибно), то недозволений. Ясно, що мова M1, íà ÿêié ми виразили полiтику безпеки P, опира¹ться на послуги:

•обчислення функцi¨ належностi Ix(A);

•обчислення логiчного виразу;

•обчислення оператора якщо x = 1, òî S → O, ÿêùî x = 0, òî

S 6→O .

M1 M2, на якiй можна визначити основнi вирази для надання послуг мовi верхнього рiвня. Можливо, що функцi¨ M2 необхiдно реалiзувати

íà ìîâi M2 бiльш низького рiвня i так дальше.

Нехай послуги, описанi на мовi M2 ми вмi¹мо гарантувати. Тодi надiйнiсть виконання полiтики P визначають повнотою ¨¨ опису в термiнах послуг U1, ..., Uk. Якщо модель P формальна, тобто мо-

âà M1 формально визнача¹ правила полiтики P, то можна довести або вiдкинути твердження, що множина наданих послуг повнiстю та однозначно визнача¹ полiтику P. Гарантi¨ виконання цих послуг

рiвносильнi гарантiям дотримання полiтики. Тодi бiльш складна задача зводиться до бiльш простих та до доведення того факту, що цих послуг достатньо для виконання полiтики. Усе це забезпечу¹ доведенiсть захисту з точки зору математики, або гарантованiсть з точки зору впевненостi у пiдтримцi полiтики iз сторони простих функцiй.

3.7.2Приклад синтезу гарантовано захищено¨ автоматизовано¨ системи

3.7.2.1. Створення моделi системи

Спочатку визначимо модель P системи, яка обробля¹ цiнну

iнформацiю. Будемо вважати, що час ¹ дискретним та приймемо значення з множини N = {1, 2, ...}, iнформацiя в системi P, âêëþ-

чаючи опис власне системи, може бути представлена у формi слiв деяко¨ гiпотетично¨ мови M над деяким скiнченним алфавiтом A.

Слiд ще раз вiдзначити, що об'¹кт в P це скiнченна множина

ñëiâ ç M, стан об'¹кта видiлене слово з множини, що визнача¹ цей об'¹кт. З поняттям об'¹кта пов'язане агрегатування iнформацi¨

â P i ïðî P.

Наприклад, об'¹ктом ¹ принтер, який можна розглядати, як автомат iз скiнченною множиною станiв, а цi стани суть слова

ìîâè M.

Iнший приклад об'¹кта файл. Множина слiв, якi можуть бути записанi у файлi, ¹ скiнченним та визнача¹ об'¹кт, а стан об'¹кта

це поточний запис у файлi, яка також ¹ словом у мовi M.

Прийнято вважати, що вся iнформацiя про P над даний мо-

мент може бути представлена у виглядi станiв скiнченно¨ множи-

ни об'¹ктiв. Тому будемо вважати, що стан системи P öå íàáið

станiв ¨¨ об'¹ктiв. Об'¹кти можуть створюватися та знищуватися,

тому можна говорити про множину об'¹ктiв системи P в момент

t, якi ми будемо позначати Qt, |Qt| < ∞.

Для кожного t N âèäiëèìî â Qt пiдмножину St ñóá'¹êòiâ. Áóäü-ÿêèé ñóá'¹êò S St ¹ описом деякого перетворення iнформа-

цi¨ в системi P. Для реалiзацi¨ цього перетворення в P необхiдно

визначити деякi ресурси (домен) та органiзувати певну вза¹модiю ресурсiв, що призводить до перетворення iнформацi¨, яку назвемо процесом. Тодi кожний суб'¹кт може знаходитись у двох станах: в формi опису, в якому суб'¹кт назива¹ться неактивiзованим, i у формi (домен, процес) в якiй суб'¹кт назива¹ться активiзованим.

Активiзувати суб'¹кт може тiльки iнший активiзований суб'¹кт. Для кожного t N на множинi St можна визначити орграф t, äå S1 i S2 ç St з'¹днанi дугою S1 → S1 тодi i тiльки тодi, коли у випадку активiзацi¨ S1 можлива активiзацiя S2.

ßêùî ñóá'¹êò S такий, що для кожного t у вершину S не входить дуга, то такий суб'¹кт будемо називати користувачем. Для

простоти припустимо, що у системi P всього два користувачi:

U1

i U2. Користувачi вважаються активiзованими за визначенням i можуть активiзувати iншi суб'¹кти.

Якщо в будь-який момент t ó ãðàôi t у вершину S не входять

дуги i не виходятьaдуги, то такi суб'¹кти вилучаються з розгляду. Позначимо S1 → S1 S1, S2 St, процедуру активiзацi¨ процесом

S1 ñóá'¹êòà S2.

ßêùî ñóá'¹êò S активiзований в момент t, то iсну¹ ¹диний активiзований суб'¹кт S0 â St, який активiзував S. Â

момент t = 0 активiзованi тiльки користувачi.

Ëåìà 1. Якщо в даний момент t активiзований суб'¹кт , то iсну¹ ¹диний користувач U, вiд iменi якого активiзований суб'¹кт

Доведення. Вiдповiдно до припущення 1 iсну¹ ¹диний суб'¹кт Sk, який активiзу¹ S. ßêùî Sk = U1, àáî Sk = U2, òî ëåìà äîâå- äåíà. ßêùî Sk 6= Ui, i = 1, 2, то iсну¹ ¹диний суб'¹кт Sk−1, ÿêèé

P i

активiзував Sk. Виходячи iз скiнченностi часу роботи системи

того факту, що у початковий момент активiзованими можуть бути тiльки користувачi, одержу¹мо на початку ланцюжка одного з них. На цьому, вiдповiдно до визначення користувачiв, ланцюжок обрива¹ться. Лема доведена.

Припущення 1 вимага¹ одиничностi iдентифiкацi¨ суб'¹ктiв. Дальше будемо припускати, що кожний об'¹кт в системi ма¹ унiкальне iм'я.

Окрiм активiзацi¨ в системi P iснують й iншi види доступу

активiзованих суб'¹ктiв до об'¹ктiв. Будемо позначати множину усiх видiв доступiв через R i будемо вважати |R| < ∞. ßêùî

ρ R, то будемо позначати множину доступiв ρ активiзованого

äî îá'¹êòà O. Нас не цiкавить, яку задачу вирiшу¹ система

лише моделю¹мо функцiонування системи послiдовнiстю доступiв.

Припущення 2. Функцiонування системи P опису¹ться по-

слiдовнiстю доступiв множини суб'¹ктiв до множини ма¹ткiв в кожний момент часу t N.

Узагальнимо введений орграф t додавши дуги S → O, якi означають можливiсть будь-якого доступу суб'¹кта S äî îá'¹êòà O у момент t, у випадку активiзацi¨ S. Позначимо Dt(S) = {O|S →

äî O âiä iìåíi S). Тодi для будь-якого t N в системi визначенi Dt(U1) i Dt(U2). Будемо вважати, що D = Dt(U1) ∩ Dt(U2) зафiксовано для усiх t, Ot = Dt(U1) Dt(U2), в початковий момент

O0 = {U1, (U2}D.

Визначення. Множина об'¹ктiв D назива¹ться загальними ресурсами системи.

Зокрема, засобами з

i знищувати об'¹кти, що не належать D. Створення та знищення будь-яких об'¹ктiв ¹ доступом в R до деяких об'¹ктiв з D (i до об'¹ктiв, що знищуються).

Раху¹мо, що з об'¹ктiв системи P побудована деяка пiдсисте-

ма, яка реалiзу¹ доступи. Будемо вважати, що будь-яке звернення суб'¹кта S за доступом ρ äî îá'¹êòà S в цю систему почина¹ться

ρ?

iз запиту, який будемо позначати S → O.

При породженнi об'¹кта суб'¹кт S зверта¹ться до вiдповiдно¨

процедури, у результатi яко¨ створю¹ться об'¹кт з унiкальним iменем. Тодi у силу леми 1, iсну¹ ¹диний користувач, вiд iменi якого активiзований суб'¹кт, що створив цей об'¹кт. Будемо говорити, що вiдповiдний користувач породив даний об'¹кт. Позначимо че-

ðåç Ot(U) множину об'¹ктiв з Ot, якi породив користувач U. Природно будемо вважати, що U Ot(U).

Для кожного t N, для кожного O Ot, O / D, iсну¹ ¹диний користувач U такий, що O Ot(U).

Доведення. Îñêiëüêè O0{U1, U2} D, òî îá'¹êò O / D, O Ot, породжений в деякий момент s, 0 < s ≤ t. Òîäi â Os iснував активiзований суб'¹кт S, що створив O. Тодi, як вiдзначено ранiше, iсну¹ ¹диний користувач U, що породив O. Лема доведена.

3.7.2.2. Створення моделi безпеки iнформацi¨ системи

Звернемося тепер до питань безпеки iнформацi¨ в системi. Якщо в R ¹ доступи read i write, обмежимося небезпекою вито-

ку iнформацi¨ через канали по пам'ятi, якi можуть виникнути при доступах до об'¹ктiв. Такими каналами може бути наступна послi-

довнiсть доступiв при s < t

w r

Ui → O в момент s i Uj → O в момент t, i 6= j.

За певних умов може стати небезпечним доступ вiд iменi користувача:

Ui →w O в момент s i Uj →r O в момент t, s < t, i 6= j.

З деякою надлишковiстю ми вичерпа¹мо можливi канали по пам'ятi, якщо будемо вважати несприятливими будь-якi доступи

ρ1, ρ2 R âèäó

якi ми i вважа¹мо каналами витоку.

Припущення 3. ßêùî O D, то доступи в (3.1) çà áóäü-ÿêèõ ρ1 i ρ2 не можуть створити канал витоку.

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

ктам присво¹нi унiкальнi iмена, то в D необхiдно мати iнформацiю

про уже присво¹нi iмена, що суперечить припущенню 3 про те, що доступи вiд iменi користувачiв не вiдображаються в iнформацi¨ загального користування. У випадку iмен можна вийти з положення, використовуючи випадковi вектори, ймовiрностi спiвпадання яких за доступний для огляду перiод роботи системи можна зробити скiльки завгодно малими. Усi побудови й висновки можливi при стохастичному способi присво¹ння iмен, але повиннi носити елементи ймовiрнiсно¨ конструкцi¨. Щоб не ускладнювати систему Щоб не ускладнювати систему стохастичними елементами можна скористатися зробленими вище припущеннями.

Òîäi â (3.1) достатньо обмежитися об'¹ктами O, що не лежать

ρ

â D. Це значить, що в одному з доступiв в (3.1) ¹ Ui → O, äå O Ot(Uj), i 6= j. Таким чином, у системи вважаються несприятливими доступи виду:

тобто доступи вiд iменi будь-якого користувача до об'¹кта, створеного iншим користувачем. Такi доступи будемо дальше називати витоком iнформацi¨.

Якщо деякий суб'¹кт S, S D, активiзова-

a

ний вiд iменi користувача Ui (тобто Ui → O), у свою чергу суб'¹- кту S наданий в момент t доступ до об'¹кта O, òî àáî O D, àáî

O Ot(Ui), або система припиня¹ роботу i виключа¹ться. Визначимо наступну полiтику безпеки:

Теорема 1. Нехай у побудованiй системi виконуються припущення 1 4. якщо всi доступи здiйснюються вiдповiдно до полi-

3.7.2.3. Моделювання умов виконання полiтики безпеки

Тепер побуду¹мо зручну для реалiзацi¨ множину послуг бiльш низького рiвня, що пiдтримують полiтику безпеки. Тобто ми хоче-

мо визначити множину умов, реалiзованих в системi Σ, таких, що

можна довести теорему про достатнiсть виконання цих умов для виконання правил полiтики безпеки.

Умова 1. (Iдентифiкацiя i автентифiкацiя). Якщо для будь-

ρ?

ÿêèõ t N, ρ R, S, O Ot, S → O, то обчисленi функцi¨ належностi S i O до множин Ot(U1), Ot(U2), D.

Умова 2. (Дозвiльна пiдсистема). Якщо S Ot(Ui), S Ot(Uj)

ρ? ρ

i S → O у момент t, òî iç i = j виходить S → O, i iç i 6= j виходить S 6→O (не дозволя¹ться доступ).

Умова 3. (вiдсутнiсть обхiдних шляхiв полiтики безпеки). Для будь-яких t N, ρ R, ÿêùî ñóá'¹êò S активiзований до моменту

ρ

t, одержав у момент t доступ S → O, то у момент t вiдбувся запит

á) ßêùî S Ot(Ui), O Ot(Uj), i 6= j, то такий доступ у момент t ñóá'¹êòà S äî îá'¹êòà O неможливий.

ρ?

Доведемо а). Якщо S → O, то за умови 1 обчисленi функцi¨

належностi та визначено, що S Ot(Ui), O Ot(Uj). ßêùî i = j,

òî ρвиконане посилання умови 2. Тодi вiдповiдно до умови 2 доступ S → O дозволений.

ρ?

Доведемо тепер б). Якщо S → O, обчисленi функцi¨ належностi та визначено, що S Ot(Ui), O Ot(Uj), i 6= j. Тодi за умови 2

Якщо доступ S → O став можливим, обминаючи запит S → O,

i S активiзований до моменту t, то зроблене припущення суперечить умовi 3. Якщо S не активiзований , то наявнiсть доступу

ρ

S → O суперечить визначенню доступу. Теорема доведена.

Теорема означа¹, що гарантувавши виконання умов 1 3, можна гарантувати виконання полiтики безпеки.

3.7.2.4. Реалiзацiя гарантовано захищено¨ автоматизовано¨ системи

Розглянемо питання про створення системи, в якiй можна з достатнiм ступенем впевненостi пiдтримувати функцi¨ 1 3. Для цього розглянемо наступну архiтектуру:

1.В кожний момент тiльки один користувач може працювати

çсистемою. Фiзична присутнiсть iншого виключена.

2.При змiнi користувачiв системи один одним, той що йде:

•запису¹ у зовнiшню память усi об'¹кти, якi вiн хоче зберегти для подальших сеансiв;

•вимика¹ живлення системи, пiсля чого весь вмiст оперативно¨

пам'ятi стира¹ться, залишаються записи у зовнiшнiй пам'ятi i постiйному запам'ятовуючому пристро¨, де зберiгаються об'¹- кти загального доступу.

3.Новий користувач органiзову¹ свою роботу iз увiмкнення системи i виклика¹ сво¨ об'¹кти iз зовнiшньо¨ пам'ятi, опираючись на об'¹кти загального користування.

4.На шлюзi зовнiшньо¨ зовнiшньо¨ пам'ятi сто¨ть шифратор K,

який зашифрову¹ на поточному ключi k всю iнформацiю, що запи-

су¹ться в зовнiшню пам'ять, включаючи назви файлiв. Навпаки, вся iнформацiя, що поступа¹ iз зовнiшньо¨ пам'ятi, розшифрову¹-

ться на поточному ключi k. Çîâíiøíÿ ïàì'ÿòü íå ì๠îïöi¨ ïåðå-

гляд директорi¨ , а будь-який запит на видачу файла функцiону¹ так, що назва файла, що запиту¹ться, шифру¹ться на поточному

êëþ÷i k. При змiнi користувачiв поточний ключ k автоматично

стира¹ться (разом iз вмiстом оперативно¨ пам'ятi), новий користувач встановлю¹ свiй ключ.

Покажемо, що функцiонування дано¨ архiтектури дозволя¹ реалiзувати всi описанi вище властивостi i, зокрема, виконати умови теорем 1 i 2.

Припущення 1 та iншi припущення в описi системи цiлком

прийнятнi для дано¨ архiтектури. Так як несприятливi стани системи та полiтики безпеки вираженi в термiнах доступiв, то для прийнятностi припущення 2 достатньо, щоб можливi обчислювальнi процеси однозначно вiдображалися в термiнах послiдовностi до-

ступiв та значень функцiй належностi об'¹ктiв до множин Ot(U1),

Ot(U2),

Якщо об'¹кт тiльки створений та знаходиться в оперативнiй пам'ятi, то доступ до нього зi сторони процесiв вiд iменi користувача, що створив його, автоматично дозволений i можна вважати, що функцiя належностi обчислена.

Якщо об'¹кт викликаний iз зовнiшньо¨ пам'ятi, то власне виклик i доступ до iнформацi¨ в об'¹ктi можливi, якщо встановлений правильний ключ, що еквiвалентно обчисленню функцi¨ належно-

ñòi äî Ot(U).

Припущення 3 i 4 виконуються, так як новий користувач працю¹ один та виклика¹ з постiйного запам'ятовуючого пристрою

функцi¨ i об'¹кти D.

В системi нема суб'¹кта, що реалiзу¹ дозвiльну систему, вона природно реалiзована за рахунок того, що розшифрована iнфор-

мацiя чита¹ться тодi i тiльки тодi, коли у шифраторi K встанов-

лений необхiдний ключ.

Якщо користувач або процес вiд його iменi зверта¹ться за доступом до об'¹кта на зовнiшнiй пам'ятi, то будь-який доступ дозволений, якщо ключ зашифровування об'¹кта (ключ творця об'¹кта) спiвпада¹ з ключом поточного користувача. Навпаки, при неспiвпаданнi ключiв допуск автоматично не дозволя¹ться, так як iм'я об'¹кта та його змiст не розшифрову¹ться правильно.

Таким чином, автоматично обчислюються функцi¨ належностi процесу i об'¹кта при зверненнi через зовнiшню память, що забезпечу¹ виконання умови 1. Також автоматично викону¹ться умова 2 про роботу дозвiльно¨ системи. Умови 1 i 2 не стосуються звернень

процесiв iз D i äî D. Томi питання iдентифiкацi¨ тут вирiшуються

за рахунок роздiлення сеансiв користувачiв i вказанi умови виконуються.

Доступ до об'¹кта можливий лише при зверненнi до зовнiшньо¨ пам'ятi через шифратор, або у випадку, коли об'¹кт створений протягом поточного сеансу, або викликаний з постiйного запам'ятову-

ючого пристрою. Якщо вважати, що доступ до об'¹ктiв в оперативнiй пам'ятi автоматично опира¹ться на даний користувачу дозвiл на доступ до них, а активiзованими можуть бути суб'¹кти вiд його ж iменi, то можна вважати, що будь-який доступ у цьому випадку викону¹ться вiдповiдно до умов 1 i 2.

Що стосу¹ться умови 3, то неможливiсть одержати доступ обминаючи дозвiльну систему визнача¹ться рознесенiстю роботи користувачiв, вiдсутнiстю пiдслуховування, необхiднiстю розшифровувати iнформацiю для одержання доступу до не¨. Це не сто-

ñó¹òüñÿ îá'¹êòiâ ç D, або тiльки що створених, де нема проблеми

iз-за рознесеностi сеансiв. Також вважа¹ться, що вiдсутн¹ фiзичне проникнення та модифiкацiя системи.

В результатi одержимо, що дана архiтектура реалiзу¹ умови теорем 1 i 2 i пiдтриму¹ полiтику безпеки.

Пiдсуму¹мо те, що забезпечу¹ гарантi¨ у побудованiй системi (тобто, що пiдтриму¹ умови теорем 1 i 2):

•забезпечення роботи тiльки одного користувача (охорона);

•вимикання живлення при змiнi користувачiв;

•ñòiéêiñòü шифратора K та збереження в та¹мницi êëþ÷iâ êî-

жного користувача.

Вiдомо, як забезпечувати цi вимоги, а гарантi¨ ¨х забезпечення ¹ гарантi¹ю захищеностi системи в сенсi вибрано¨ полiтики безпеки.

Вiдзначимо деякi сторони побудовано¨ моделi, якi можуть зустрiчатися дальше.

1)Гарантi¨ побудованi при чiткiй полiтицi безпеки.

2)Для пiдтримки полiтики необхiдна iдентифiкацiя об'¹ктiв (плюс обчислення додатково¨ iдентифiкацiйно¨ функцi¨).

3)Для пiдтримки полiтики необхiдна автентифiкацiя суб'¹кта, що зверта¹ться за допуском.

4)Значна частина умов визнача¹ функцiональну захищенiсть власне системи захисту.

3.7.3Приклад використання результатiв синтезу моделей безпеки для доведення гарантованостi захисту систем

3.7.3.1. Загальнi вiдомостi

Представлений вище пiдхiд може також використовуватися для аналiзу систем захисту, який дозволя¹ виявити слабкостi в системах, якi проектуються або уже iснують. При цьому i¹рархiя мов може бути неоднозначною, головне зручнiсть представлення та аналiзу.

Проте проводити подiбний аналiз в кожнiй системi дорого. Крiм того, методика проведення аналiзу державних систем ¹ конфiденцiйною iнформацi¹ю. Вихiд був знайдений у тому, що умови теорем, якi доводять пiдтримку полiтики безпеки (включаючи вiдповiдну полiтику) сформулювати без доведень у виглядi стандарту.

Такий пiдхiд вперше застосували в США у 1983 роцi, опублiкувавши вiдкрито проект стандарту iз захисту iнформацi¨ в системах обробки даних, де були сформульованi вимоги гарантовано¨ пiдтримки двох класiв полiтик безпеки дискрецiйно¨ та полiтики MLS. Потiм цей метод був застосований у 1987 роцi для опису гарантовано захищених розподiлених мереж, що пiдтримували цi ж полiтики, i у 1991 роцi для опису вимог гарантовано захищених баз даних. Цей же шлях використали канадцi та ¹вропейськi держави, створивши сво¨ стандарти захисту.

Стандарт був прийнятий мiнiстерством оборони США у 1985 роцi. Повна назва документа Computer System Evaluation Criteri- a (критерi¨ безпеки комп'ютерних систем ). Найчастiше його називають за кольором обложки, у якiй вiн був опублiкованийЖовтогаряча книга .

Жовтогаряча книга була призначена для наступних цiлей:

•надати виробникам стандарт, що встановлю¹, якими засобами

безпеки слiд оснащувати сво¨ продукти, щоб поставляти на ринок доступнi системи, що задовольняють вимогам гарантовано¨ захищеностi (маючи на увазi, насамперед, захист вiд розкриття даних) для використання при обробцi цiнно¨ iнформацi¨;

•надавати метрику для приймання та оцiнки захищеностi систем

обробки даних, призначених для обробки службово¨ та iншо¨ цiнно¨ iнформацi¨;

•забезпечити базу для дослiдження вимог до вибору захищених

систем.

Розглядаються два типи оцiнки:

•без участi середовища, у якому працю¹ технiка;

•у конкретному середовищi (ця процедура назива¹ться атестуванням).

Ó1992 роцi Державна технiчна комiсiя Росi¨ видала вiд свого iменi документи, аналогiчнi за завданнями та змiстом до Жовтогарячо¨ книги .

3.7.3.2. Основне твердження та основнi визначенняЖовтогарячо¨ книги

В усiх документах, пов'язаних з Жовтогарячою книгою , прийнято одне розумiння фрази забезпечення безпеки iнформацi¨. Це розумiння прийма¹ться як аксiома та формулю¹ться наступним чином: безпека + контроль за доступом.

Àêñiîìà. Комп'ютерна система назива¹ться безпечною, якщо вона забезпечу¹ контроль за доступом iнформацi¨ так, що тiльки належним чином уповноваженi особи або процеси, якi функцiонують вiд ¨х iменi, мають право читати, писати, ство-

рювати або знищувати iнформацiю.

З цi¹¨ аксiоми витiка¹ шiсть фундаментальних вимог до захищеностi комп'ютерних систем. Для ¨х розумiння нагада¹мо та введемо деякi визначення.

Полiтика безпеки [security policy] це набiр норм, правил i практичних прийомiв, якi управлiння, захист та розподiл цiнно¨ iнформацi¨ в данiй органiзацi¨.

Iдентифiкацiя [identi cation] це розпiзнавання iменi об'¹кта. Об'¹кт, що iдентифiку¹ться, ¹ однозначно розпiзнаваний.

Автентифiкацiя [authentication] це пiдтвердження того, що пред'явлене iм'я вiдповiда¹ об'¹кту.

Ядро безпеки [Trusted Computing Base (TCB)] сукупнiсть механiзмiв захисту в обчислювальнiй системi (включаючи апара-

тну та програмну складовi), якi вiдповiдають за пiдтримку полiтики безпеки.

Аудит [audit] або вiдслiдковування, пiдзвiтнiсть це ре¹страцiя подiй, якi дозволяють вiдновити та довести факт того, що подi¨ вiдбулися.

3.7.3.3.Таксономiя вимог Жовтогарячо¨ книги

ÓЖовтогарячiй книзi пропонуються три категорi¨ вимог безпеки полiтика безпеки, аудит i гарантi¨, в рамках яких сформульованi шiсть базових вимог безпеки:

•полiтика забезпечення безпеки, мiтки в рамках полiтики безпеки;

•iдентифiкацiя i автентифiкацiя, ре¹страцiя i облiк в рамках аудита;

•контроль коректностi функцiонування засобiв захисту, безпе-

рервнiсть захисту в рамках гарантi¨.

Першi чотири вимоги спрямованi безпосередньо на забезпече-

ння безпеки iнформацi¨, а двi останнi на якiсть самих засобiв захисту.

Полiтика безпеки

Вимога 1. Полiтика забезпечення безпеки. Система повинна пiдтримувати точно визначену полiтику безпеки. Можливiсть здiйснення суб'¹ктами доступу повинна визначатися на основi ¨х iдентифiкацi¨ та набору правил управлiння доступом. Наданi на атестацiю для використання обчислювальнi системи повиннi передбачати реалiзацiю мандатного контролю забезпечення безпеки, в рамках якого допуска¹ться ефективна реалiзацiя правил доступу, орi¹нтованих на обробку конфiденцiйно¨ (наприклад, та¹мно¨) iнформацi¨. Цi правила включають також такi вимоги: нi одна особа, що не володi¹ належним для допущеного персоналу дiапазоном повноважень, не одержить доступу до секретно¨ iнформацi¨. Крiм того, також необхiднi дискрецiйнi засоби управлiння безпекою, якi гарантують, що тiльки вибранi користувачi або групи користувачiв

можуть одержати доступ до даних (реалiзацiя принципу тiльки тi, яким необхiдно знати ).

Вимога 2. Мiтки. З об'¹ктами повиннi бути асоцiйованi мiтки безпеки, що використовуються як атрибути контролю доступу. Для того, щоб управляти доступом до iнформацi¨ вiдповiдно до правил мандатно¨ полiтики, повинна бути передбачена можливiсть маркiрувати кожний об'¹кт мiткою, яка надiйно iдентифiку¹ ступiнь цiнностi об'¹кта (наприклад, секретностi) i/або режими допуску, представленi тим суб'¹ктам, якi потенцiйно можуть зробити запит на доступ до об'¹кта.

Вимога 3. Iдентифiкацiя i автентифiкацiя. Усi суб'¹кти повиннi мати унiкальнi iдентифiкатори. Контроль доступу повинен здiйснюватися на основi результатiв iдентифiкацi¨ суб'¹кта та об'¹кта доступу, пiдтвердження дiйсностi ¨х iдентифiкаторiв (автентифiкацi¨) i правил розмежування доступу. Данi, що використовуються для iдентифiкацi¨ та автентифiкацi¨ повиннi бути захищенi вiд несанкцiонованого доступу, модифiкацi¨ та знищення i повиннi бути асоцiйованi зi всiма компонентами комп'ютерно¨ системи, функцiонування яких критичне з точки зору безпеки.

Вимога 4. Ре¹страцiя та облiк. Для визначення ступеня вiдповiдальностi користувачiв за дi¨ в системi, всi подi¨. що вiдбуваються в нiй та мають значення з точки зору безпеки, повиннi вiдслiдковуватися i ре¹струватися в захищеному протоколi. Система ре¹страцi¨ повинна здiйснювати аналiз загального потоку подiй i видiляти з нього тiльки тi подi¨, якi впливають для скорочення протоколу та пiдвищення ефективностi його аналiзу. протокол подiй повинен бути надiйно захищеним вiд несанкцiонованого доступу, модифiкацi¨ та знищення.

Гарантi¨

Вимога 5. Контроль гарантiй функцiонування засобiв захисту. Засоби захисту повиннi мати незалежнi апаратнi i/або програмнi компоненти, що забезпечують працездатнiсть функцiй захисту. Це означа¹, що усi засоби захисту, що забезпечують полiтику безпеки, управлiння атрибутами та мiтками безпеки, iдентифiкацiю та автентифiкацiю, ре¹страцiю i облiк, повиннi знаходити-

ся пiд контролем засобiв, що перевiряють коректнiсть ¨х функцiонування. Основний принцип контролю гарантiй поляга¹ в тому, що засоби контролю повиннi бути повнiстю незалежними вiд засобiв захисту.

Вимога 6. Безперервнiсть захисту. Усi засоби захисту (у тому числi i тi, що реалiзують дану вимогу) повиннi бути захищеними вiд несанкцiонованого втручання i/або вимкнення, причому цей захист повинен бути постiйним i безперервним у будь-якому режимi функцiонування системи захисту i комп'ютерно¨ системи у цiлому. Дана вимога поширю¹ться на весь жить житт¹вий цикл комп'ютерно¨ системи. Крiм того, ¨¨ виконання ¹ одним з ключових аспектiв формального доказу безпеки системи.

Таксономiя вимог Жовтогарячо¨ книги наведена на рис. 3.26.

3.7.3.4. Таксономiя критерi¨в Жовтогарячо¨ книги

Приведенi вище базовi вимоги до безпеки служать основою для критерi¨в, що утворюють ¹дину шкалу оцiнки безпеки, яка визна- ча¹ сiм класiв безпеки.

`Жовтогаряча книга передбача¹ чотири групи критерi¨в, якi вiдповiдають рiзним ступiням захищеностi: вiд мiнiмально¨ (група D) до формально доведено¨ (група A). Кожна група включа¹ один або декiлька класiв. Групи D (мiнiмальний захист) i A (верифiкований захист) мiстять по одному класу [класи D1 (мiнiмальний захист) i A1 (формальна верифiкацiя) вiдповiдно], група C (дискрецiйний захист) класи C1 (дискрецiйний захист) C2 (керування доступом), а група B (мандатний захист) B1 (захист iз застосуванням мiток безпеки), B2 (структурований захист), B3 (домени безпеки), що характеризуються рiзними наборами вимог безпеки. Рiвень безпеки збiльшу¹ться вiд групи D до групи A, а всерединi групи iз збiльшенням номера класу.

Група D. Мiнiмальний захист.

Êëàñ D. Мiнiмальний захист. Цей клас зарезервований для тих систем, якi були пiдданi оцiнцi, але в яких не вдалося досягнути виконання вимог бiльш високих класiв оцiнок.

Група Ñ. Дискрецiйний захист.

Ðèñ. 3.26. Таксономiя вимог Жовтогарячо¨ книги

Група Ñ характеризу¹ться наявнiстю довiльного управлiння доступом i ре¹страцi¹ю дiй суб'¹ктiв.

Êëàñ Ñ1. Дискрецiйний захист. Системи цього класу задовольняють вимогам забезпечення роздiлення користувачiв i iнформацi¨

та включають засоби контролю i управлiння доступом, якi дозволяють задавати обмеження для iндивiдуальних користувачiв. що да¹ ¨м можливiсть захищати свою приватну iнформацiю вiд iнших користувачiв. Клас С1 розрахований на багатокористувальницькi системи, в яких здiйсню¹ться спiльна обробка даних одного рiвня секретностi.

Êëàñ Ñ2. Управлiння доступом. Системи цього класу здiйснюють бiльш вибiркове управлiння доступом, нiж системи класу Ñ1, за допомогою застосування засобiв iндивiдуального контролю за дiями користувачiв, ре¹страцi¹ю, облiком подiй та видiленням ресурсiв.

Группа Â. Мандатний захист.

Основнi вимоги цi¹¨ групи нормативне управлiння доступом

çвикористанням мiток безпеки, пiдтримка моделi i полiтики безпеки, а також наявнiстю специфiкацiй на функцi¨ ядра безпеки. Для систем цi¹¨ групи монiтор вза¹модiй повинен контролювати усi подi¨ в системi.

Êëàñ Â1. Захист iз застосуванням мiток безпеки. Системи класу Â1 повиннi вiдповiдати всiм вимогам, що пред'являються до систем класу Ñ2, i, крiм того, повиннi пiдтримувати певну визначе- ну неформально модель безпеки, маркiрування даних и нормативе управлення доступом. При експортi з системи iнформацiя повинна пiдлягати маркiруванню. Виявленi у процесi тестування недолiки, повиннi бути усунутi.

Êëàñ Â2. Структурований захист. Для вiдповiдностi класу Â2 ядро безпеки системи повинно пiдтримувати формально визначе- ну i чiтко документовану модель безпеки, що передбача¹ довiльне та нормативне керування доступом, яке розповсюджу¹ться порiвняно з системами класу Â1 на всi суб'¹кти. Крiм того, повинен здiйснюватися контроль прихованих каналiв витоку iнформацi¨. В структурi ядра безпеки повиннi бути видiленi елементи, критичнi

çточки зору безпеки. Iнтерфейс ядра безпеки повинен бути чiтко визначеним, а ¨¨ архiтектура та реалiзацiя повиннi бути з урахуванням можливостi проведення тестових випробувань. Порiвняно з класом Â1 повиннi бути пiдсиленi засоби автентифiкацi¨. Управлiння безпекою здiйсню¹ться адмiнiстратором системи. Повиннi бути передбаченi засоби управлiння конфiгурацi¹ю.

Êëàñ ÂÇ. Домени безпеки. Для вiдповiдностi цьому класу ядро безпеки системи повинен пiдтримувати монiтор вза¹модiй, який контролю¹ всi типи доступу суб'¹ктiв до об'¹ктiв, якi неможливо обiйти. Крiм того, ядро безпеки повинно бути структурованим з метою вилучення з не¨ пiдсистем, якi не вiдповiдають за реалiзацiю функцiй захисту, i бути достатньо компактним для ефективного тестування i аналiзу. У ходi розробки й реалiзацi¨ ядра безпеки повиннi застосовуватися методи попередження адмiнiстратора при виникненнi подiй, що мають значення для безпеки системи. Необхiдна наявнiсть вiдновлення працездатностi системи.

Група À. Верифiкований захист.

Дана група характеризу¹ться застосуванням формальних методiв верифiкацi¨ коректностi роботи механiзмiв управлiння доступом (довiльного i нормативного). Необхiдна додаткова документацiя, яка демонстру¹, що архiтектура i реалiзацiя ядра безпеки вiдповiда¹ вимогам безпеки.

Êëàñ À1. Формальна верифiкацiя. Системи класу À1 функцiонально еквiвалентнi системам класу ÂÇ, i до них не пред'явля¹ться нiяких додаткових функцiональних вимог. На вiдмiну вiд систем класу ÂÇ в ходi разработки повиннi застосовуватися формальнi методи верифiкацi¨, що дозволя¹ з високою впевненiстю одержати коректну реалiзацiю функцiй захисту. Процес доведення адекватностi реалiзацi¨ почина¹ться на раннiй стадi¨ розробки з побудовою формально¨ моделi полiтики безпеки i специфiкацiй високого рiвня. Для забезпечення методiв верифiкацi¨ систем класу А1 повиннi мати бiльш потужнi засоби управлiння конфiгурацi¹ю та захищену процедуру дистрибуцi¨.

Приведеннi класи безпеки надовго визначили основнi концепцi¨ безпеки i хiд розвитку засобiв захисту.

Ðîçäië 4

Забезпечення гарантiй виконання вимог полiтик безпеки

4.1Загальнi поняття про розроблення програмного забезпечення захисту iнформацi¨

4.1.1Особливостi розроблення програмного забезпечення захисту iнформацi¨

Методи побудови програмного забезпечення автоматизованих систем можна роздiлити на двi групи [31]:

1)такi, що вiдносяться до довiльного програмного забезпечення автоматизовано¨ системи, наприклад:

•i¹рархiчний метод розробки;

•дослiдження коректностi та верифiкацiя.

2)специфiчнi тiльки для систем захисту розглядаються в теорi¨ безпечних систем.

4.1.1.1. I¹рархiчний метод розробки програмного забезпечення

Вiдповiдно до принципу абстракцi¨ при проектуваннi автоматизовано¨ системи розробники використати по меншiй мiрi два напрями: вiд апаратури угору до вiртуально¨ машини, що представля¹ автоматизовану систему, або вiд вiртуально¨ машини вни- з до реального обладнання. Це i ¹ два основних методи проектування метод знизу вверх в метод сверху вниз. Решта методiв за сво¹ю суттю зводяться до цих двох або ¹ ¨х сполученням.

Метод знизу вверх передбача¹ початок проектування з основного апаратного обладнання системи. При проектуваннi мо-

дулi розбиваються на ряд шарiв, причому нульовий шар вiртуально¨ системи утворю¹ апаратура. Шари, що реалiзують одну або декiлька властивостей, додаються послiдовно поки не буде одержана бажана вiртуальна машина.

До недолiкiв методу проектування знизу вверх вiдносять:

•необхiднiсть iз самого початку приймати рiшення про вибiр

способу реалiзацi¨ компонентiв автоматизовано¨ системи за допомогою апаратури, мiкропрограм або програм, що зробити дуже важко;

•можливiсть проектування автоматизовано¨ системи тiльки пiсля розробки апаратури;

•розходження мiж реальною автоматизованою системою та ви-

значеною в технiчному завданнi.

При використаннi методу зверху вниз (i¹рархiчний метод) виходять вiд вiртуально¨ машини, що представля¹ автоматизовану систему, з необхiдними властивостями та послiдовно розробляються шари вiртуально¨ системи аж до апаратури. У цьому випадку проектування здiйсню¹ться у наступнiй послiдовностi. Визнача¹ться рiвень рiвень абстракцi¨ опису компонентiв автоматизовано¨ системи вищого шару. Дальше систематично проводиться аналiз, чи достатньо визначенi компоненти, щоб ¨х можна було реалiзувати, використовуючи деякi примiтивнi поняття. Якщо нi, то кожна функцiя кожно¨ компоненти представля¹ться функцiями компонентiв наступного шару, якому вiдповiда¹ бiльш низький рiвень абстракцi¨, i знову проводиться аналiз на можливiсть ¨х реалiзацi¨. В i¹рархiчному методi доцiльно використати структурний принцип та принцип модульного проектування.

Структурний принцип ма¹ фундаментальне значення та склада¹ основу бiльшостi реалiзацiй. Вiдповiдно до цього принципу, для побудови програмного забезпечення необхiднi тiльки три основнi конструкцi¨:

•функцiональний блок;

•конструкцiя узагальненого циклу;

•конструкцiя прийняття двiйкового рiшення.

Функцiональний блок можна представити як окремий обчи- слювальний оператор або як будь-яку iншу реальну послiдовнiсть обчислень з ¹диним входом i ¹диним виходом, як в пiдпрограмi.

Органiзацiя циклу в лiтературi часто згаду¹ться як елемент dowhile. Конструкцiя прийняття двiйкового рiшення назива¹ться if- then-else.

Зазначимо, що цi конструкцi¨ можуть власне розглядатися як функцiональнi блоки, оскiльки вони мають тiльки один вхiд i один вихiд. Таким чином, можна ввести перетворення операцi¨ циклу в функцiональний блок i у подальше розглядати сякий такий оператор циклу еквiвалентом (дещо бiльш складного) функцiонального блоку. Аналогiчно можна ввести перетворення конструкцi¨ прийняття рiшення до функцiонального блоку. Нарештi, можна привести будь-яку послiдовнiсть функцiональних елементiв до одного функцiонального елементу. У цей же час зворотна послiдовнiсть перетворень може бути використаною в процесi проектування програми по спаднiй схемi, тобто виходячи з ¹диного функцiонального блоку, який поступово розклада¹ться у складну структуру основних елементiв.

Принцип модульного проектування поляга¹ у роздiленнi програм на функцiонально самостiйнi частини (модулi), що забезпечують замiннiсть, кодифiкацiю, видалення та доповнення складових чистин.

Переваги використання модульного принципу полягають у наступному:

•спрощу¹ться налагодження програм, так як обмежений доступ

до модуля та однозначнiсть його прояву виключа¹ вплив помилок в iнших, пов'язаних з ним, модулях на його функцiонування;

•забезпечу¹ться можливiсть органiзацi¨ спiльно¨ роботи великих

колективiв розробникiв, так як кожний програмiст ма¹ справу з незалежною вiд iнших частиною програми;

•пiдвищу¹ться якiсть програми, так як вiдносно малий розмiр

модулiв i, як наслiдок, невелика складнiсть ¨х дозволяють провести бiльш повну перевiрку програми.

4.1.1.2. Дослiдження коректностi реалiзацi¨ та верифiкацiя автоматизовано¨ системи

Поняття коректностi або правильностi припуска¹ вiдповiднiсть об'¹кта, що перевiря¹ться, деякому еталонному об'¹кту або сукупностi формалiзованих еталонних характеристик i правил. Коректнiсть програмного забезпечення при розробцi найбiльш повно визнача¹ться ступенем вiдповiдностi до формалiзованих вимог програмно¨ специфiкацi¨. В специфiкацiях вiдобража¹ться сукупнiсть етелонних характеристик, властивостей та умов, яким повинна вiдповiдати програма. Основну частину специфiкацi¨ складають функцiональнi критерi¨ та характеристики. Вихiдною програмною специфiкацi¹ю, якiй повинна вiдповiдати програма, ¹ технiчне завдання.

При вiдсутностi повнiстю формалiзовано¨ специфiкацi¨ вимог як технiчне завдання, якому повинна вiдповiдати автоматизована система i результати ¨¨ функцiонування, iнодi використовують неформалiзованi уявлення розробника, користувача або замовника програм. Проте поняття коректностi програм по вiдношенню до запитiв користувача або замовника сполучено з невизначенiстю власне еталону, якому повинна вiдповiдати автоматизована система. Для складних програм завжди iсну¹ ризик виявити ¨¨ некоректнiсть (за думкою користувача або замовника) при формальнiй коректностi вiдносно специфiкацiй внаслiдок неточностi власне специфiкацiй.

Традицiйний погляд на специфiкацiю вимог поляга¹ у тому, що вона представля¹ документ на природнiй мовi, який ¹ iнтерфейсом мiж замовником та виробником. Хоча при пiдготовцi документу може передувати деяка вза¹модiя, саме цей документ у значнiй мiрi виступа¹ як вiдправна точка виробника програм.

Таким чином, можна зробити висновок про те, що створення сукупностi вза¹мозв'язаних несуперечливих специфiкацiй ¹ необхiдною базою для забезпечення коректностi програми, що проекту¹ться. При цьому специфiкацi¨ повиннi:

•бути формальними;

•дозволяти перевiряти несуперечливiсть та повноту вимог замовника;

•служити основою для подальшого формалiзованого проектува-

ííÿ.

Iсну¹ декiлька пiдходiв до визначення специфiкацiй вимог. Специфiкацiя як опис. Замовник вида¹ специфiкацiю, щоб

виробники могли забезпечити його тим виробом, який вiн бажа¹, тому замовник бачить цей документ головним чином як опис системи, яку вiн хотiв би мати. У принципi, в описi повинно бути вказано, що повинна i що не повинна робити система. На практицi звичайно за умовчанням передбача¹ться, що система повинна робити, що уточню¹ться в специфiкацi¨, i не повинна робити нiчого бiльше. У цьому поляга¹ головна проблема з описовою стороною специфiкацi¨. передбача¹ться, що замовник завжди точно зна¹ все, що система повинна i не повинна робити. Бiльш того, у подальшому передбача¹ться, що замовник повнiстю перенiс це знання у специфiкований документ.

Специфiкацiя як припис. Виробник дивиться на специфiкований документ як на набiр складових частин, що пiдлягають складанню, щоб розв'язати проблему замовника. Такий приписний погляд зумовлю¹ться не тiльки труднощами створення описового документа (як указувалось вище), але й вiдомостями, якi навмисно або ненавмисно розширюють або обмежують свободу виробника.

Договiрна методологiя. В рамках опис замовника припис виробнику специфiкацiя розгляда¹ться як формальний розподiл мiж сторонами. Що стосу¹ться замовника, то вiн обмовля¹ мiнiмально прийнятне, тодi як виробник максимально потрiбне. Договiр пропону¹ться i прийма¹ться при зародженнi системи i закiнчу¹ться пiсля завершення системи, тодi замовник прийма¹ систему як таку, що вiдповiда¹ його мiнiмальним вимогам. Пiд час виготовлення системи у принципi не передбача¹ться нiяких вза¹модiй, навiть якщо виробник пiдозрю¹, що запропоноване не зовсiм вiдповiда¹ тому, що замовник бажа¹ бачити у дiйсностi.

Специфiкацiя як модель. Сучаснi бiльш строгi уявлення про специфiкацi¨ трактують ¨¨ як модель системи. При умовi, що семантика, яка лежить в основi моделi, в достатнiй мiрi об рунтована, така специфiкацiя забезпечу¹ чiтке формулювання вимог.

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

забезпечить припинення розробки системи, в принципi не здатно¨ задовольнити вимогам.

Моделi як опис системи мають наступнi вiдмiтнi риси порiвняно з iншими способами формального опису:

•добре сполучення спадного та висхiдного пiдходiв до ¨х розробки з можливiстю вибору абстрактного опису;

•можливiсть опису паралельно¨, розподiлено¨ та циклiчно¨ роботи;

•можливiсть вибору рiзноманiтних формалiзованих апаратiв

для опису системи.

Основна перевага використання формально¨ моделi поляга¹ у можливостi дослiдження ¨¨ за допомогою особливостей системи, що пiдляга¹ моделюванню. Якщо заснувати формальний метод розробки на математичнiй моделi а потiв дослiджуючи модель, можна виявити такi гранi поведiнки системи, якi у протилежному випадку не були би очевидними до бiльш пiзнiших стадiй.

Так як цiльовим об'¹ктом проектування ¹ автоматизована система, то модель може описувати або власне систему, або ¨¨ поведiнку, тобто зовнiшнi прояви функцiонування автоматизовано¨ системи. Модель, що опису¹ поведiнку автоматизовано¨ системи у порiвняннi з моделлю власне автоматизовано¨ системи, ма¹ одну важливу перевагу вона може бути перевiрена i оцiнена як користувачами, так i замовниками, оскiльки замовники не знають як повинна працювати автоматизована система, але зате вони представляють, що вона повинна робити. У результатi такого моделювання може бути перевiрена коректнiсть специфiкацiй вiдносно вихiдно¨ постановки задачi, тобто технiчного завдання. Окрiм того, критерi¨ правильностi вважаються достатнiми за умови, що специфiкацiя представля¹ собою вичерпний опис зовнiшньо¨ поведiнки об'¹кта при всiх можливих (або запланованих) ситуацiях його використання.

Як було вiдзначено вище, при розробцi автоматизовано¨ системи, особливо ¨¨ компонентiв, що представляють систему захисту iнформацi¨, для забезпечення високих гарантiй вiдсутностi несправностей та наступного доказу того, що система функцiону¹ вiдповiдно до вимог технiчного завдання, використовуються формальнi пiдходи до ¨¨ проектування.

Формальне проектування алгоритмiв базу¹ться, в основному, на мовах алгоритмiчних логiк, якi включають висловлювання виду

Q{S}R,

що читаються наступним чином: якщо до виконання оператора S була виконана умова Q, то пiсля нього буде R. Òóò Q назива¹ться передумовою, а R постумовою. Як передумова, так i постумова

¹ предикатами.

Розгляд програм я деякого перетворювача предикатiв дозволя¹ прямо визначити зв'язок мiж початковими та кiнцевими станами без будь-яких посилань на промiжнi стани, якi можуть виникнути пiд час виконання програм.

Перевага представлення алгоритму у виглядi перетворювача предикатiв поляга¹ у тому, що воно да¹ можливiсть:

•аналiзувати алгоритми як математичнi об'¹кти;

•давати формальний опис алгоритму, який дозволя¹ iнтелектуально охопити алгоритм;

•синтезувати алгоритми за представленими специфiкацiями;

•провести формальну верифiкацiю алгоритму, тобто довести ко-

ректнiсть його реалiзацi¨.

Методологiя формально¨ розробки та доведення коректностi алгоритмiв на теперiшнiй час добре розробленi та викладенi у цiлому рядi робiт. Коротко суть цих методiв зводиться до наступного:

•розробка алгоритму проводится методом послiдовно¨ декомпо-

зицi¨, з розбивкою загально¨ задачi, що розв'язу¹ться алгоритмом, на ряд бiльш дрiбних пiдзадач;

•критерi¹м деталiзацi¨ пiдзадач ¹ можливiсть ¨х реалiзацi¨ за допомогою однi¹¨ конструкцi¨ розгалудження або циклу;

•розбивання однi¹¨ задачi на пiдзадачi передбача¹ формулюван-

ня перед- i постумов для кожно¨ пiдзадачi з метою ¨х коректного проектування та подальшо¨ верифiкацi¨.

Для доведення коректностi алгоритму (верифiкацiя ) формулю¹ться математична теорема Q{S}R, яка потiм доводиться. До-

ведення теореми про коректнiсть прийнято розбивати на двi ча- стини. Одна частина служить для для доведення того, що алгоритм, представлений для розгляду, взагалi може завершити роботу

(проводится аналiз усiх циклiв). В iншiй частинi доводиться коректнiсть постумови у припущеннi, що алгоритм завершу¹ роботу.

4.1.2Надiйнiсть та стiйкiсть програмного забезпечення

До неправильного функцiонування автоматизовано¨ системи призводять помилки в програмному забезпеченнi та вiдмова апаратури. Тому в органiчно зв'язаному комплексi неможливо бува¹, по меншiй мiрi на початковiй стадi¨ пошуку, роздiлити причини вiдмови. У связку з цим вводять поняття надiйностi програмного забезпечення, пiд яким розумiють властивiсть об'¹кта зберiгати у часi значення усiх параметрiв, що характеризують здатнiсть виконувати потрiбнi функцi¨ у заданих режимах застосування, технiчного обслуговування, ремонту, зберiгання та транспортування.

Незважаючи на явну подiбнiсть у визначеннях надiйностi для апаратних засобiв та програмного забезпечення фактично мiж цими надiйностями зберiгаються принциповi вiдмiнностi. Програма у бiльшостi випадкiв не може вiдмовити випадково. Помилки у програмному забезпеченнi, допущенi при його створеннi, залежать вiд технологi¨, органiзацi¨ та квалiфiкацi¨ виконавцiв i в принципi не ¹ функцi¹ю часу. Причиною вiдмов, що виникають iз-зi цих помилок та фiксованих як випадковий процес, ¹ не час функцiонування системи, а набiр вхiдних даних, що склалися до моменту вiдмови.

Загроза вiдмови функцiонування автоматизовано¨ системи може бути викликана як цiлеспрямованими дiями зловмисникiв, так i недостатньою надiйнiстю апаратури та програмного забезпечення, що входить до складу автоматизовано¨ системи. При забезпеченнi захисту автоматизовано¨ системи вiд загрози вiдмови функцiонування звичайно роблять наступнi припущення.

Вважа¹ться, що надiйнiсть апаратних компонентiв достатньо висока, i у практичному планi цi¹ю складовою у загальнiй надiйностi автоматизовано¨ системи можна нехтувати. Бiльш того, темпи морального старiння обчислювально¨ технiки значно випереджають темпи ¨¨ фiзичного старiння, i замiна обчислювально¨ технiки, як правило, вiдбува¹ться до виходу ¨¨ з ладу. На теперiшнiй час (за умови дотримання правил експлуатацi¨) практично

не розгляда¹ться можливiсть втрати даних унаслiдок втрати машинними носiями iнформацi¨ сво¨х функцiональних властивостей. Таким чином, надiйнiсть функцiонування автоматизовано¨ системи може бути зведена до надiйностi функцiонування програмного забезпечення, що входить до його складу.

Iнше припущення зв'язане з тим, що прийнято не розрiзняти природу причин збо¨в та вiдмов роботи автоматизовано¨ системи, тобто для надiйностi функцiонування автоматизовано¨ системи неважно, чи викликанi вони дiями зловмисника чи вони зв'язанi з помилками розробки, важливо. як i в якому обсязi вiдбудеться ¨х вiдбивання.

Iснують два основних пiдходи до забезпечення захисту програмного забезпечення автоматизовано¨ системи вiд загрози вiдмови функцiонування попередження несправностей [fault avoidance] òà стiйкостi до вiдмов [fault tolerance].

Стiйкiсть до вiдмов передбача¹, що помилки програмного забезпечення, що залишилися, виявляються пiд час виконання програми та вiдбиваються за рахунок використання програмно¨, iнформацiйно¨ та часовой надмiрностi. попередження несправностей пов'язане з аналiзом природи помилок, що виникли на рiзних фазах створення програмного забезпечення, i причин ¨хнього виникнення.

4.1.3Методи забезпечення надiйностi програмного забезпечення

4.1.3.1.Забезпечення стiйкостi до вiдмов програмного

забезпечення

Неможливiсть забезпечити у процесi створення автоматизовано¨ системи ¨¨ абсолютно¨ захищеностi вiд загрози вiдмови функцiонування навiть при вiдсутностi зловмисних дiй заставля¹ шукати додатковi методи та засоби пiдвищення безпеки функцiонування програмного забезпечення на етапi експлуатацi¨. Для цього розробляються та застосовуються методи оперативного виявлення дефектiв при виконаннi програм та спотворення даних введенням у них часово¨, iнформацiйно¨ та програмно¨ надмiрностi. Цi ж види

надмiрностi використовуються для оперативного вiдновлення спотворених програм та попередження можливостi розвитку загроз до рiвня, що порушу¹ безпеку автоматизовано¨ системи.

Для забезпечення високо¨ надiйностi та безпеки функцiонування автоматизовано¨ системи необхiднi обчислювальнi ресурси для максимально швидкого виявлення прояву дефектiв, можливо то- чно¨ класифiкацi¨ типу уже наявних та ймовiрних наслiдкiв спотворень, а також ля автоматизованих заходiв, що забезпечують швидке вiдновлення нормального функцiонування автоматизовано¨ системи. Неминучiсть помилок у складних автоматизованих системах, спотворень вхiдних даних та iнший аномалiй приводять до необхiдностi регулярно¨ перевiрки стану i процесу виконання програм, а також схоронностi даних. У процесi проектування необхiдно розроблювати надiйнi i безпечнi програми та бази даних, стiйкi до рiзних збурювань та здатнi зберiгати достатню якiсть результатiв у всiх реальних умовах функцiонування. У будь-яких ситуацiях насамперед повиннi виключатися катастрофiчнi наслiдки дефектiв та довготривалi вiдмови або в максимальнiй мiрi зм'я- кшуватися ¨х вплив на результати, що видаються користувачевi.

Часова надмiрнiсть поляга¹ у використаннi деяко¨ частини продуктивностi комп'ютера для контролю виконання програм та вiдновлення (рестарту) обчислювального процесу. Для цього при проектуваннi автоматизовано¨ системи повинен передбачатися запас продуктивностi, який потiм буде використовуватися системами контролю i для пiдвищення надiйностi та безпеки функцiонування. Значення часово¨ надмiрностi залежить вiд вимог до безпеки функцiонування або оброблення iнформацi¨ i знаходиться в межах вiд 5 до 10% продуктивностi вiд три-чотирикратного дублювання в мажоритарних обчислювальних комплексах.

Iнформацiйна надмiрнiсть поляга¹ у дублюваннi нагромаджених вихiдних та промiжних даних, що обробляються програмами. Надмiрнiсть використову¹ться для збереження достовiрних даних. якi у найбiльшiй мiрi впливають на нормальне функцiонування автоматизовано¨ системи i вимагають значного часу на вiдновлення. Такi данi звичайно характеризують деякi iнтегральнi вiдомостi про зовнiшнiй управляючий процес; у випадку ¨х руйнування може перерватися процес управлiння зовнiшнiми об'¹ктами

або оброблення ¨х iнформацi¨, що вiдобража¹ться на безпецi автоматизовано¨ системи.

Програмна надмiрнiсть використову¹ться для контролю та забезпечення достовiрностi найбiльш важливих рiшень з управлiння та обробки iнформацi¨. Вона поляга¹ у спiвставленнi результатiв обробки однакових вихiдних даних рiзними програмами та виключеннi спотворення результатiв, зумовлених рiзними аномалiями. програмна надмiрнiсть необхiдна також для реалiзацi¨ засобiв автоматичного контролю та вiдновлення даних з використанням iнформацiйно¨ надмiрностi i для функцiонування всiх засобiв захисту, що мають часову надмiрнiсть.

Послiдовний характер виконання програм центральним процесором приводить до того, що засоби оперативного програмного контролю починають працювати пiсля виконання прикладних i сервiсних програм. Тому засоби програмного контролю звичайно не можуть виявляти виникнення спотворення обчислювального процесу або даних (первинну помилку) та фiксують, як правило, тiльки наслiдки первинного спотворення (вторинну помилку). Результати первинного спотворення у рядi випадкiв можуть розвиватися у часi та примати катастрофiчний характер вiдмови при збiльшеннi часу запiзнювання у визначеннi наслiдкiв первинно¨ помилки.

Забезпечення стiйкостi до вiдмов програмного забезпечення автоматизовано¨ системи ма¹ застосування в основному до прикладного програмного забезпечення, так як у цьому випадку реалiзацiя завдання контролю поклада¹ться на операцiйну систему. Що стосу¹ться власне операцiйно¨ системи, то даний пiдхiд тут практи- чно не працю¹, так як для не¨ необхiдна своя контролююча операцiйна надсистема . яку необхiдно також контролювати, i т.iн. Тому для операцiйних систем застосовують методи попередження несправностей програмного забезпечення.

4.1.3.2. Попередження несправностей у програмному забезпеченнi

За останнi декiлька десятилiть у рiзних кра¨нах та фiрмах вiдпрацьовуються процеси створення, розвитку та застосування про-

грам для комп'ютерiв. Цi процеси прийнято описувати моделями житт¹вого циклу програм рiзних класiв та призначення. У моделi житт¹вий цикл структуру¹ться рядом значних фаз або етапiв, кожний з яких характеризу¹ться достатньо визначеними цiлями та результатами. Так як основнi промiжнi та кiнцевi цiлi створення та застосувань програм одного класу ¹ достатньо близькими, то i моделi житт¹вого циклу для аналогiчних типiв програмних засобiв у значнiй мiрi ¹ подiбними. Головнi вiдмiнностi полягають у видiленнi найбiльш важливих процесiв, а також способiв ¨х групування та вiдображення. При цьому важливу роль вiдiграють класи i параметри програм, якi (iнодi неявно) визначають первiсне формування моделей житт¹вого циклу.

На теперiшнiй час моделi житт¹вого циклу реалiзуються у виглядi стандартiв. Аналiз сучасних стандартiв дозволя¹ зробити висновок про те, що основними фазами створення програмного забезпечення ¹:

•аналiз i специфiкацiя вимог;

•проектування;

•виконання.

Розглянемо змiст кожно¨ з цих фаз, в контекстi розв'язання задачi попередження несправностей програмного забезпечення.

Фаза аналiзу та виконання вимог

Прагнення до досягнення бiльшо¨ надiйностi програмного забезпечення приверта¹ особливу увагу до найбiльш раннiх фаз циклу створення програм. Найновiша та найменше розроблена галузь програмно¨ надiйностi це специфiкацi¨ вимог. Аналiз всi¹¨ сукупностi вимог до системи технiчного завдання викону¹ться на початковiй фазi створення програм. Технiчне завдання склада¹ться на основi перелiку вимог, що пред'являються до системи замовником (класи задач, ¨х характеристики та особливостi, режим роботи автоматизовано¨ системи, сполучення iз зовнiшнiми об'¹ктами, пропускна здатнiсть, термiн вiдповiдi i т.iн. при заданих обмеженнях на вартiсть, тривалiсть розробки та iнше). Мета створення технiчного завдання уточнити та сформулювати задачi, що покладаються на систему, узгодити вимоги замовника та

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

У загальному випадку iнформацi¨, що мiститься у технiчному завданнi, може бути достатньо для розробки повноцiнних детальних специфiкацiй. Тому аналiз вимог до операцiйно¨ системи та доповнення технiчного завдання вiдсутнiми даними ¹ необхiдним кроком при розробцi. Одержаний таким чином опис операцiйно¨ системи прийнято називати ескiзним проектом, а саме ескiзний проект буде розглядатися розробником у подальшому як основа для фази проектування.

Успiхи в теорi¨ програмування та обчислень забезпечили використання формальних методiв при розробцi програмного забезпечення. Формальний метод розробки систем склада¹ться з трьох компонент:

•формальний запис специфiкацiй та описiв проектiв:

•методики одержання реалiзацiй iз специфiкацiй;

•складання правил висновку (або доведення) того, що реалiзацi¨

вiдповiдають цим специфiкацiям.

Перевага формальних методiв поляга¹ у тому, що системи, розробленi з використанням подiбного пiдходу, мають принципово високу якiсть. При цьому пiдвищення якостi досяга¹ться двома шляхами:

•побудовою специфiкацiй у виглядi чiткого, вичерпного, недвозначного та легкого для перевiрки математичного твердження;

•здiйснення верифiкацi¨ пiд час розробки програмного забезпе-

чення.

Òåðìií верифiкацiя використову¹ться для позначення процедур, якi показують, що кожний крок розробки ¹ адекватною реалiзацi¹ю опису програми, одержаного на попередньому кроцi, i що кiнцева програма ¹ наслiдком цi¹¨ специфiкацi¨.

Розробка формально¨ специфiкацi¨ потребу¹ значних зусиль. проте, як показу¹ практика, бiльшiсть помилок, що виявляються у кiнцi житт¹вого циклу програми, i, отже, найбiльш дорогих та складних для виправлення, виника¹ iз-за помилок в специфiкацi¨. Таким чином, для попередження несправностей програмного

забезпечення розглянутiй фазi необхiдно придiляти особливу увагу.

Фаза проектування

Головне завдання системного проектування програмного забезпечення поляга¹ у тому, щоб на основi ескiзного проекту розробити сукупнiсть основних характеристик програмного забезпечення, що проекту¹ться, його архiтектуру, тобто склад та iнтерфейс модулiв. Наступнi кроки проектування пов'язанi з уточненням ескiзного проекту, тобто з розробкою формалiзованих описiв, що представляють в сукупностi внутрiшнi завдання на проектування компонентiв (окремих процедур) програмного забезпечення, та ¨х алгоритмiчних реалiзацiй.

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

Фаза виконання

Фаза виконання включа¹ в себе кодування, iнтегрування, а також тестування та налагодження. Приймемо пiдхiд, вiдповiдно до якого тестування служить iнструментом вимiрювання, але не забезпечення надiйностi програм. Тому тестування виключа¹ться з подальшого розгляду.

З кожно¨ iз фаз створення програмного забезпечення пов'язанi специфiчнi помилки. З фазою аналiзу та специфiкацiй вимог системнi помилки, з фазою проектування алгоритмiчнi i з фазою кодування програмнi.

Системнi помилки визначаються насамперед неповною iнформацi¹ю про реальнi процеси, що вiдбуваються в джерелах та споживачах iнформацi¨. Пiд час аналiзу вимоги не завжди вда¹ться точно сформулювати цiльову задачу всi¹¨ системи, а також задачi основних груп програм, i цi задачi уточнюються у процесi проектування. Вiдповiдно до цього локалiзуються та виявляються вiдхилення вiд уточнено¨ задачi, якi можуть квалiфiкуватися як системнi помилки.

Äî алгоритмiчних помилок насамперед вiдносять помилки, обумовленi некоректною постановкою задач, що розв'язуються окремими частинами програмного забезпечення. До них також вiдносять помилки зв'язкiв модулiв та функцiональних груп програм. У бiльшостi випадкiв ¨х та кож можна звести до помилок у специфiкацiях.

Програмнi помилки за кiлькiстю i типами визначаються, у першу чергу, ступенем автоматизацi¨ програмування та глибиною формалiзованого контролю текстiв програм. Програмнi помилки сильно залежать вiд вибрано¨ мови програмування. Наявна статистика показу¹, що найбiльшу вагу мають помилки неповно¨ програмно¨ реалiзацi¨ функцiй алгоритму або невiрний порядок реалiзацi¨ функцiй.

Таким чином, на основi аналiзу фаз створення програмного забезпечення та помилок, що допускаються на них, можна зробити висновок про те, що двома основними рiзновидами помилок ¹:

•невiрне специфiкування як усього програмного комплексу, так i окремих його складових;

•функцiональна невiдповiднiсть програми алгоритму.

Усунення даних помилок шлях до забезпечення захисту вiд збо¨в та несправностей програмного забезпечення.

4.2Технологiчна безпека розроблення систем захисту

4.2.1Технологiчна безпека програмного забезпечення

4.2.1.1.Ненавмиснi дестабiлiзуючi фактори, що впливають на безпеку функцiонування програмного забезпечення

Даний роздiл присвячений методам виявлення та попередження ненавмисних загроз безпецi функцiонування програмного забезпечення, зниження вiдповiдних ризикiв до допустимого рiвня та визначення реально досягнутого степеня безпеки використання iнформацiйно¨ системи. У цьому випадку говорять про алгоритмi- чну i програмно-технiчну безпеку, використовуючи для стислостi термiн технологiчна безпека [16]. Основною ненавмисною загрозою тут можна можна розглядати наявнiсть внутрiшнiх дефектiв програмного забезпечення, якi викликанi помилками проектування та реалiзацi¨.

Аналiз технологiчно¨ безпеки iнформацiйно¨ системи може базуватися на моделi вза¹модi¨ основних компонент, представлених на рис. 4.1.

Об'¹ктами уразливостi тут розглядаються:

•динамiчний обчислювальний процес оброблення даних, автома-

тизовано¨ пiдготовки рiшень та вироблення управляючих впливiв;

•iнформацiя, що нагромаджена у базах даних;

•об'¹ктний код програм, що викону¹ться обчислювальними засобами у процесi функцiонування iнформацiйно¨ системи;

•iнформацiя, що вида¹ться споживачам та на виконавчi механiзми.

На цi об'¹кти впливають рiзноманiтнi дестабiлiзуючi фактори, якi роздiлити на внутрiшнi, що властивi об'¹ктам уразливостi, i зовнiшнi, зумовленi середовищем, у якому цi об'¹кти функцiонують. внутрiшнiми джерелами загроз безпецi функцiонування складних iнформацiйних систем можуть бути:

Ðèñ. 4.1. Модель вза¹модi¨ основних компонент технологiчно¨ безпеки

•системнi помилки при постановцi целей та завдань проектуван-

ня iнформацiйно¨ системи, формулюванню вимог до функцiй та характеристик розв'язку задач, визначеннi умов та параметрiв зовнiшнього середовища, у якому передбача¹ться застосовувати iнформацiйну систему;

•алгоритмiчнi помилки проектування при безпосереднiй алгори-

тмiзацi¨ функцiй програмних засобiв та баз даних, при визна- ченнi структури та вза¹модi¨ компонент комплексiв програм, а

також при використаннi iнформацi¨ баз даних;

•помилки програмування в текстах програм та описах даних, а

також i вихiднiй та результативнiй документацi¨ на компоненти iнформацiйно¨ системи;

•недостатня ефективнiсть методiв та засобiв оперативного захи-

сту програм та даних i забезпечення безпеки функцiонування iнформацiйно¨ системи в умовах випадкових негативних впливiв.

Зовнiшнiми дестабiлiзуючими факторами, що створюють за-

грози безпецi функцiонування перелiченим об'¹ктам уразливостi iнформацiйно¨ системи можуть бути:

•помилки оперативного та обслуговуючого персоналу в процесi експлуатацi¨ iнформацiйно¨ системи;

•спотворення в каналах телекомунiкацi¨ iнформацi¨, що посту-

пають вiд зовнiшнiх джерел та таких, що передаються споживачами, а також недопустимi змiни характеристик потокiв iнформацi¨;

•збо¨ та вiдмови апаратури;

•змiна складу та конфiгурацi¨ iнформацiйно¨ системи за межi,

перевiренi при випробуваннях або сертифiкацi¨.

Повне усунення перелiчених загроз принципово неможливе. Завдання поляга¹ у виявленнi факторiв, вiд яких вони залежать, у створеннi методiв та засобiв зменшення ¨х впливу на безпеку iнформацiйно¨ системи, а також у ефективному розподiлi ресурсiв для забезпечення захисту, рiвномiцного по вiдношенню до усiх негативних впливiв.

Завдяки сучасним досягненням мiкроелектронiки значно знизився вплив збо¨в та вiдмов обчислювальних засобiв на безпеку iнформацiйних систем. проте помилки персоналу, спотворення даних в каналах телекомунiкацiй, а також випадковi (при вiдмовах апаратури) i необхiднi змiни конфiгурацi¨ обчислювальних засобiв залишаються сутт¹вими загрозами безпеки обчислювальних систем. Негативний вплив цих факторiв може бути значно знижений вiдповiдними методами та засобами захисту в програмах та даних.

Для нашо¨ постановки задачi придiлимо основну увагу внутрiшнiм дестабiлiзуючим факторам, рiзноманiтним помилкам прое-

ктування та експлуатацi¨, якi вiдсутностi зловмисних дiй здiйснюють найбiльший вплив на безпеку функцiонування iнформацiйно¨ системи.

Вiдмiнностi мiж очiкуваними та одержаними результатами функцiонування програмного забезпечення можуть бути наслiдком помилок не тiльки у створених програмах i даних, але i системних помилок в первинних вимогах специфiкацiй, що ¹ основою при створеннi iнформацiйно¨ системи. Цим власне проявля¹ться об'¹ктивна реальнiсть, що поляга¹ у неможливостi абсолютно¨ коректностi та повноти вихiдних специфiкацiй, складних критичних iнформацiйних систем. На практицi у процесi розробки програмного забезпечення вихiднi вимоги уточнюються та деталiзуються за узгодженням мiж замовником та розробником. Основою для таких уточнень ¹ неформалiзованi уявлення та знання спецiалiстiв, а також результати промiжних етапiв проектування. Проте встановити помилковiсть вихiдних еталонiв ще важче, нiж виявити помилки у створеному програмному забезпеченнi, так як принципово вiдсутнi формалiзованi данi, якi можна використати як еталоннi, i ¨х замiнюють неформалiзованими уявленнями замовника та розробникiв.

Óрезультатi важливо¨ особливостi процесу виявлення помилок

âпрограмах i даних складних, критичних iнформацiйних системах ¹ вiдсутнiсть повнiстю визначеного еталону, якому повиннi вiдповiдати текст та результати розроблено¨ програми. Тому встановити наявнiсть та локалiзувати помилку безпосереднiм порiвнянням програми або даних без дефектiв у бiльшостi випадкiв неможливо при налагодженнi та тестуваннi звичайно спочатку виявляються вториннi помилки, тобто наслiдки та результати прояву деяких дефектiв, якi слiд квалiфiкувати як первиннi помилки або причи- ни виявлення аномалiй. Локалiзацiя та коректування таких первинних помилок призводить до усунення помилок, що на початку виявляються в результатах функцiонування програм.

Прояви помилок у рiзнiй мiрi впливають на працездатнiсть програм i ¨х не можна цiлком квалiфiкувати як вiдмови. У найгiршому випадку вторинна помилка проявля¹ться як повна вiдмова втрата працездатностi програмного забезпечення на тривали час, загрожуючи безпецi. Значне спотворення програм, даних або

грам, типом мови програмування, рiвнем автоматизацi¨ технологi¨ розробки та багатьма iншими факторами.

Точне представлення повного числа невиявлених помилок у комплексi програм прямими методами вимiрювання ¹ неможливим. Проте iснують непрямi шляхи для наближено¨ статистично¨ оцiнки ¨х повного числа або ймовiрностi помилки у кожнiй командi програми. Такi оцiнки базуються на побудовi математичних моделей з припущенням про сильну кореляцiю мiж загальною кiлькiстю та iнтенсивнiстю прояву помилок у деякому комплексi програм пiсля його тестування та випробувань протягом заданого ча- су.

Шляхом аналiзу та узагальнення ряду експериментальних даних реальних розробок запропоновано декiлька математичних моделей, що описують основнi закономiрностi змiни сумарно¨ кiлькостi вторинних помилок у програмах. Цi моделi призначенi для оцiнки:

•надiйностi та безпеки функцiонування програм у процесi випробувань та експлуатацi¨;

•числа помилок, що залишилося невиявленими в програмах, що пiдлягають аналiзу;

•часу, необхiдного для виявлення наступно¨ помилки у програмi;

•часу, необхiдного для виявлення усiх помилок iз заданою ймо-

âiðíiñòþ.

Зменшення числа помилок в iнформацiйнiй системi та iнтенсивностi ¨х виявлення не ¹ необмеженим. Пiсля налагодження на протязi деякого часу iнтенсивнiсть виявлення помилок при найбiльш жорстких умовах тестування понижу¹ться настiльки, що колектив розробникiв може попасти в зону нечутливостi до полок та вiдмов. При такiй низькiй iнтенсивностi важко прогнозувати витрати часу, що необхiднi для виявлення чергово¨ помилки. Склада¹ться уявлення про повну вiдсутнiсть помилок, про неможливiсть та безцiльнiсть ¨х пошуку, внаслiдок чого зусилля на налагодження скорочуються i iнтенсивнiсть виявлення помилок ще бiльше знижу¹ться. Цiй граничнiй iнтенсивностi виявлення вiдмов вiдповiда¹ напрацювання на виявлену помилку, при якiй скорочу¹ться покращення характеристик програмного забезпечення на етапах налагодження та випробувань.

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

4.2.1.2. Методи зниження рiвня загроз безпецi iнформацiйно¨ системи, викликаних дефектами

програмного забезпечення

Рiвень та вплив внутрiшнiх дестабiлiзуючих факторiв, а також деяких зовнiшнiх загроз на безпеку застосування iнформацiйно¨ системи визнача¹ться у найбiльшiй мiрi якiстю технологiй проектування, розробки, супроводження та документування iнформацiйних систем та ¨х основно¨ компоненти програмного забезпече- ння. При обмежених ресурсах на розробку програмного забезпе- чення необхiдне управлiння забезпечення якiстю протягом усього циклу створення програм i даних. Таке управлiння передбача¹ високу дисциплiну та проектувальницьку культуру всього колективу спецiалiстiв, пiдтриману методиками, типовими документами та засобами автоматизацi¨ розробки. Крiм того, управлiння забезпеченням якостi програмного забезпечення передбача¹ формалiзацiю та сертифiкацiю розробки, а також видiлення у спецiальний процес поетапне вимiрювання та аналiз поточного стану якостi створюваних та застосовуваних компонент. Спроби створення критичних, розподiлених iнформацiйних систем без використання ефективних технологiй та засобiв автоматизацi¨ проектування програмного забезпечення пов'язанi з високим ризиком провалу внаслiдок труднощiв забезпечення задано¨ безпеки функцiонування таких систем.

У сучасних автоматизованих технологiя створення та розви-

тку програмного забезпечення з позицi¨ забезпечення ¨х потенцiйно¨ технологiчно¨ безпеки можна видiлити методи та засоби, що дозволяють:

•попереджати дефекти проектування за рахунок ефективних те-

хнологiй забезпечення усього житт¹вого циклу комплексiв програм та даних;

•виявляти та усувати помилки проектування шляхом система-

тичного тестування на всiх етапах житт¹вого циклу програмного забезпечення;

•засвiдчувати досягнуту якiсть та безпеку застосування про-

грамного забезпечення у процесi ¨х сертифiкацi¨ перед передаванням в експлуатацiю.

Комплексне, координоване застосування таких методiв та засобiв у процесi створення та розвитку програмного забезпечення дозволя¹ виключити деякi види загроз або значно послабити ¨х вплив. Тим самим рiвень досягнуто¨ безпеки системи ста¹ передбаченим та керованим, безпосередньо залежним вiд ресурсiв, що видiляються на його досягнення, а, головне, вiд якостi та ефективностi технологi¨, що використову¹ться на усiх етапах житт¹вого циклу iнформацiйно¨ системи.

При створеннi критичних iнформацiйних систем високо¨ складностi важлива проблема поляга¹ у правильному системотехнiчному та iнформацiйно-технологiчному проектi, що забезпечу¹ високi споживацькi властивостi та безпеку системи. Одночасно в силу високо¨ якостi проробки та документування проекту створю¹ться основа для пониження трудомiсткостi налагодження, випробувань та особливо супроводження та розвитку прикладно¨ системи. Спiльне використання сучасних CASE-технологiй та мов програмування здатне знизити трудомiсткiсть розробки складних програмних засобiв та скоротити тривалiсть ¨х проектування.

Базовим принципом сучасних методiв та технологiй створення прикладного програмного забезпечення ¹ багатократне використання ¨ вiдпрацьованих технiчних рiшень на рiзноманiтних апаратних та операцiйних платформах. На теперiшнiй час за деякими оцiнками 10 15% прикладних програм створю¹ться заново, у той час як основна частина програмних засобiв переноситься з iнших платформ, комплексу¹ться та збира¹ться з готових, випробува-

них, повторно використовуваних компонент гарантовано¨ якостi. Це забезпечу¹ багатократне пiдвищення продуктивностi працi розробникiв iнформацiйних систем, скорочення термiнiв ¨х створення, високу якiсть та безпеку проектiв.

Попередженню дефектiв в складних, розподiлених система сприя¹ розвиток та застосування концепцi¨ i стандартiв вiдкритих систем. При цьому слiд враховувати, що ¨х використання сполучено з деякими суперечливими тенденцiями в номенклатурi та величинах загроз, що вiдбиваються на технологiчнiй безпецi програмного забезпечення. Масове перенесення програм та даних на рiзноманiтнi апаратнi та операцiйнi платформи сприя¹ розповсюдженню дефектiв та невиявлених помилок, що залишаються в переносимих компонентах. Проте переносимi компоненти, як правило, ретельнiше тестуються та випробовуються i тим самим мають бiльш високу якiсть, нiж тi, якi створенi без орi¹нтацi¨ на переносимiсть. Стандартизацiя та глибокий формалiзований контроль iнтерфейсiв та протоколiв вза¹модi¨ компонент iнформацiйно¨ системи дозволяють створювати складнi розподiленi системи високо¨ надiйностi та безпеки. Суворе дотримання та контроль вiдповiдностi до стандартiв вiдкритих систем (почати автоматично здiйсню¹ться CASE-засобами) ¹ високоефективним методом попередження ряду класiв помилок та пiдвищення технологiчно¨ безпеки системи.

Тестування ¹ основним методом вимiрювання якостi та визна- чення реально¨ безпеки застосування програмного забезпечення на будь-яких етапах розробки. Результати тестування та вимiрювання показникiв якостi порiвнюють з вимогами технiчного завдання або специфiкацiй для визначення мiри вiдповiдностi до пред'явлених вимог, одержаних розробником вiд замовника. Наявнiсть таких достатньо повних еталонiв, як сукупнiсть вимог технiчного завдання та поетапна ¨х декомпозицiя у специфiкацiях, ¹ необхiдною базою для тестування при промiжних та завершальних випробуваннях.

Безпосередньою метою тестування ¹ виявлення, локалiзацiя та усунення помилок у програмах i даних. Важливою особливiстю тестування складних iнформацiйних систем ¹ необхiднiсть достатньо повно¨ ¨х перевiрки при обмеженiй тривалостi випробувань.

Це визнача¹ доцiльнiсть ретельного планування тестування з урахуванням усiх результатiв, одержаних на попереднiх етапах розробки. При плануваннi основне завдання поляга¹ у досягненнi максимально¨ достовiрностi результатiв, визначеннi якостi та безпеки системи при обмежених затратах ресурсiв усiх видiв на проведення тестування.

За обмежений, вiдносно короткий перiод тестування важко провести достатньо обширне тестування, що достовiрно демонстру¹ досягнутi показники якостi та безпеки, i гарантувати виконання усiх технiчних вимог до складно¨ iнформацiйно¨ системи. Тому для забезпечення високо¨ якостi доцiльно проводити випробування не тiльки завершено¨ системи, але й на рядi промiжних етапiв розробки перевiряти стан та характеристики компонент проекту. Для цього до початку розробки у процесi формування технiчного завдання формулюються план та основнi положення методики забезпечення якостi. Поетапних випробувань компонент та визна- чення характеристик, допустимих для продовження розробки на наступному етапi. Одночасно здiйсню¹ться поетапне уточнення технiчного завдання та методики випробувань системи.

Iз-за високо¨ складностi критичних систем систематичному тестування ¨х програмного забезпечення приходиться придiляти по- части стiльки часу та сил, скiльки безпосереднiй розробцi. Недооцiнка необхiдностi планомiрного тестування у процесi розробки проекту приводить до рiзкого зростання витрат на виявлення та виправлення помилок у процесi експлуатацi¨, а також до зниження безпеки використання таких iнформацiйних систем. Систематичне скоординоване тестування реалiзацiй функцiй системи в усьому доступному рiзноманiттi можливих ситуацiй та умов зовнiшнього середовища сприя¹ виявленню внутрiшнiх дефектiв. Що загрожують катастрофiчними наслiдками для безпеки системи.

На жаль, не iсну¹ ефективних методик навчання планомiрному, систематичному тестування та методам створення генераторiв тестiв. Низка культура та технологiя супроводження програмного забезпечення, вiдсутнiсть систематично¨ вза¹модi¨ з багато чисельними користувачами та урахування ¨х вимог визначають безперспективнiсть та неконкурентноздатнiсть багатьох проектiв крити- чних iнформацiйних систем.

Для засвiдчення якостi та безпеки застосування складних критичних систем програмне забезпечення, що використову¹ться в них, слiд пiддавати обов'язковiй сертифiкацi¨ . Проте сертифiкацiя засвiдчу¹ якiсть та безпеку застосування iнформацiйно¨ системи тiльки в умовах, що обмеженi конкретними стандартами та нормативно-технiчними документами, з деякою скiнченною ймовiрнiстю. У реальних умовах експлуатацi¨ принципово можливi вiдхилення характеристик зовнiшнього середовища функцiонування iнформацiйно¨ системи за межi, обмеженi сертифiкатом , i ситуацi¨, неперевiренi при сертифiкацiйних випробуваннях. Цi обставини здатнi викликати наслiдки, що загрожують безпецi функцiонування iнформацiйно¨ системи. Наявнiсть сертифiкату у програмного забезпечення для критичних систем ¹ необхiдною умовою для ¨х допуску до експлуатацi¨, проте будь-який сертифiкат на складнi системи не може гарантувати абсолютну безпеку ¨х застосування i завжди залиша¹ться деякий ризик виникнення катастрофiчних ситуацiй.

4.2.2Формування iнструментально-технологiчних комплексiв

Неможливiсть забезпечити у процесi створення iнформацiйно¨ системи ¨¨ абсолютно¨ захищеностi навiть при вiдсутностi зловмисних дiй заставля¹ шукати додатковi методи та засоби пiдвищення безпеки функцiонування програмного забезпечення на етапi експлуатацi¨. Для цього розробляються та застосовуються методи оперативного виявлення дефектiв при виконаннi програм та спотворень даних шляхом введення в них часово¨, iнформацiйно¨ та програмно¨ надлишковостi. Цi ж види надлишковостi використовуються для оперативного вiдновлення спотворених програм i даних та попередження можливостi розвитку загроз до рiвня, що порушу¹ безпеку функцiонування системи.

Для забезпечення високо¨ надiйностi та безпеки функцiонування програмного забезпечення необхiднi обчислювальнi ресурси для максимально швидкого виявлення дефектiв, можливо точно¨ класифiкацi¨ типу уже наявних та ймовiрних наслiдкiв спотворень, а також для автоматизованих заходiв, що забезпечують швидке

вiдновлення нормального функцiонування iнформацiйно¨ системи. Невiдворотнiсть помилок у складних iнформацiйних системах, спотворень вхiдних даних та iнших аномалiй призводить до необхiдностi регулярно¨ перевiрки стану та процесу виконання програм, а також схоронностi даних. У процесi проектування необхiдно розроблювати надiйне та безпечне програмне забезпечення, стiйке до рiзних збурень та здатне зберiгати достатню якiсть результатiв в усiх реальних умовах функцiонування. У будь-яких ситуацiях насамперед повиннi виключатися катастрофiчнi наслiдки дефектiв i тривалi вiдмови або у максимальнiй мiрi зм'якшуватися ¨х вплив на результати, що видаються користувачу.

Часова надмiрнiсть поляга¹ у використаннi деяко¨ частини продуктивностi ЕОМ для контролю виконання програм та вiдновлення (рестарту) обчислювального процесу. Для цього при проектуваннi системи повинен передбачатися запас продуктивностi, який буде потiм використовуватися для контролю та пiдвищення надiйностi та безпеки функцiонування. Величина часово¨ надмiрностi залежить вiд вимог до безпеки функцiонування критичних систем управлiння та обробки iнформацi¨ та знаходить у межах вiд 5-10 % продуктивностi до три-чотирикратного дублювання в мажоритарних обчислювальних комплексах.

Iнформацiйна надмiрнiсть поляга¹ у дублюваннi накопичених вхiдних та промiжних даних, що обробляються програмами. Надмiрнiсть використову¹ться для збереження достовiрностi даних, якi у найбiльшiй мiрi впливають на нормальне функцiонування системи та вимагають значного часу на вiдновлення. Такi данi зви- чайно характеризують деякi iнтегральнi вiдомостi про зовнiшнiй процес, який пiдляга¹ управлiнню, i у випадку ¨х руйнування може перерватися процес управлiння зовнiшнiми об'¹ктами або оброблення ¨х iнформацi¨, що вiдбива¹ться на безпецi системи.

Програмна надмiрнiсть використову¹ться для контролю та забезпечення достовiрностi найбiльш важливих з управлiння та оброблення iнформацi¨. Вона поляга¹ у спiвставленнi результатiв оброблення однакових вхiдних даних рiзними програмами та виключеннi спотворення результатiв, зумовлених рiзноманiтними аномалiями. Програмна надмiрнiсть необхiдна також для реалiзацi¨ засобiв автоматичного контролю та вiдновлення даних з вико-

ристанням iнформацiйно¨ надмiрностi i для функцiонування усiх засобiв захисту, що використовують часову надмiрнiсть.

Послiдовний характер виконання програм процесором ЕОМ призводить до того, що засоби оперативного програмного контролю включаються пiсля виконання прикладних та сервiсних програм (рис. 4.2). Тому засоби програмного контролю звичайно не можуть виявляти виникнення спотворення обчислювального процесу або даних (первинну помилку) та фiксують, як правило) тiльки наслiдки первинного спотворення (вторинну помилку). Результати первинного спотворення у рядi випадкiв можуть розвиватися у часi та приймати катастрофiчний характер вiдмови при збiльшеннi запiзнювання у визначеннi наслiдкiв первинно¨ помилки.

Факт наявностi спотворення бажано виявляти при мiнiмальних затратах ресурсiв ЕОМ та з мiнiмальним запiзнюванням. Це приводить до використання i¹рархiчних схем контролю, при яких декiлька методiв застосовуються послiдовно в порядку поглиблення контролю та збiльшення затрат до достовiрного виявлення спотворення. Програми аналiзу проявiв дефектiв та вiдновлення обчислювального процесу, програм та даних готують та реалiзують необхiднi процедури з лiквiдацi¨ наслiдкiв виявлених дефектiв. При цьому доцiльно концентрувати ресурси на потенцiйно найбiльш небезпечних дефектах та достатньо частих режимах вiдновлення:

•при спотвореннях програм та даних у пам'ятi ЕОМ;

•при перевантаженнях з продуктивностi.

Залежно вiд ступеню прояву та причин виявлення спотворень можливi наступнi оперативнi заходи для лiквiдацi¨ ¨х наслiдкiв, вiдновлення iнформацi¨ та збереження безпеки оброблення даних та управлiння (див. рис. 4.2):

•iгнорування виявленого спотворення внаслiдок слабкого впливу на весь процес функцiонування та вихiднi результати;

•виключення повiдомлення з оброблення внаслiдок його спотво-

рення або труднощiв майбутнього вiдновлення обчислювального процесу;

•повторення функцiонально¨ групи програм при тих же вхiдних даних або вiдновлення даних у процесi наступного оброблення;

•короткочасне припинення розв'язку задач дано¨ групи прикла-

Ðèñ. 4.2. Органiзацiя контролю та забезпечення безпеки обчислювального процесу

дних програм до оновлення вхiдних даних;

•перестроювання режиму роботи або структури системи для пониження впливу перезавантаження або у зв'язку з втратою iн-

формацi¨ про хiд процесу оброблення даних i управлiння;

•перехiд на резервну ЕОМ з накопиченою iнформацi¹ю про хiд

процесу управлiння або вiдновлення iнформацi¨ за рахунок ¨¨ дублювання;

•вiдновлення процесу управлiння або оброблення iнформацi¨ з

режиму початкового пуску всi¹¨ iнформацiйно¨ системи з оперативним утручанням обслуговуючого персоналу.

Останнiй метод не завжди гаранту¹ цiлiснiсть, безперервнiсть та повну безпеку процесу вза¹модi¨ ЕОМ з об'¹ктами зовнiшнього середовища, а при решта типах оперативно¨ реакцi¨ та виявленi дефекти обов'язково проявляються бiльш або менш тривалi вiдхилення вiд нормального ходу процесу оброблення iнформацi¨.

Вибiр методу оперативного вiдновлення здiйсню¹ться в умовах значно¨ невизначеностi вiдомостей про характер ситуацi¨, що переду¹ вiдмовi, та ступеня ¨¨ можливого впливу на працездатнiсть та безпеку iнформацiйно¨ системи. Вiдновлення працездатностi бажано проводити настiльки швидко, щоб ситуацiю вiдмови можна було би звести до рiвня збою. Оперативна iндикацiя вiдхилення вiд норми при функцiонуваннi iнформацiйно¨ системи дозволя¹ користувачам контролювати аномалi¨ у процесi оброблення даних i в особливих випадках оперативно контролювати аномалi¨ у процесi оброблення даних i в особливих випадках коректувати реакцiю системи захисту на виявлення спотворень.

Поряд з оперативною реакцi¹ю на спотворення в iнформацiйнiй системi повинно вестися накопичення iнформацi¨ про усi прояви дефектiв з тим, що використати цi данi для локалiзацi¨ первинного джерела помилок та виправлення вiдповiдних програм, даних або компонент апаратури. Пiдготовку, статистичне оброблення та нагромадження даних iз проявiв спотворень доцiльно проводити автоматично з видаванням перiодично або за запитом зведених даних на iндикацiю для пiдготовки спецiалiстами рiшень про коригування програм або вiдновлення апаратури.

Таким чином, введення надлишковостi у програми та данi сприя¹ пiдвищенню якостi функцiонування iнформацiйно¨ системи. Особливо великий вплив надлишковостi може здiйснити на надiйнiсть та безпеку розв'язання задач у критичних системах реального часу. При цьому можливе зниження затрат на налаго-

дження та часткове забезпечення необхiдно¨ надiйностi та безпеки системи за рахунок пiдвищення завадостiйкостi, оперативного контролю та вiдновлення функцiонування програм i даних. Засоби оперативного захисту обчислювального процесу, програм i даних, у свою чергу, ¹ складними системами i не застрахованi вiд помилок, здатних призвести до порушення безпеки функцiонування системи. Тому необхiдний комплексний аналiз, розподiл ресурсiв та видiв надлишковостi для максималiзацi¨ безпеки застосування критичних iнформацiйних систем.

4.2.3 Формування моделюючих комплексiв

Значну допомогу у пiдвищеннi технологiчно¨ безпеки складних, критичних iнформацiйних систем може надати систематизацiя видiв тестування та впорядковане ¨х проведення при випробуваннях. Цi види тестування орi¹нтованi на диференцiальне виявлення певних видiв дефектiв. Для кожного виду тестування доцiльно розроблювати методику його виконання з визначення параметрiв, що пiдлягають контролю, та очiкуваних, еталонних результатiв. Крiм того, при заключних випробуваннях або сертифiкацi¨ повинно проводитися iнтегральне тестування при максимально широкому варiюваннi тестiв в умовах, що вiдповiдають нормальнiй експлуатацi¨.

Тестування повноти розв'язку функцiональних задач при типових вхiдних даних призначене для виявлення для виявлення помилок функцiонування в типових умовах, визначених технiчним завданням на базову версiю програмного забезпечення. Первинним еталоном ¹ мета та завдання створення програмного забезпечення. Вiдповiдно до цих завдань створю¹ться докладне формалiзоване технiчне завдання та специфiкацiя вимог на комплекс програм, якi ¹ основними еталонами при створеннi даного виду тестiв. Для систем реального часу тести мiстять в основному динамiчнi та стохастичнi данi. Цi данi iмiтуються моделями реальних об'¹ктiв зовнiшнього середовища. Результати тестування обробляються та порiвнюються еталонами переважно автоматично. Деяка частина тестiв може мiстити детермiнованi вхiднi данi, для аналiзу яких часто застосовуються рiзноманiтнi системи графiчного

вiдображення.

Тестування функцiонування програм у критичних ситуацiях за умовами та логiкою розв'язку задач (стресове тестування) призначенi для випробувань виконання програм у нештатних ситуацiях, якi реалiзуються рiдко, але ¹ важливими для безпечного функцiонування системи обробки iнформацi¨ та управлiння. Для розробки таких тестiв створюються сценарi¨ критичних сполучень значень вхiдних даних та умов розв'язку задач, при яких необхiдно перевiрити функцiонування програм та можна очiкувати спотворення результатiв та вiдмови. Такi, стресовi, нештатнi сполучення готуються ручним способом або передбача¹ться ¨х реалiзацiя у складi даних стохастичних тестiв у реальному часi. Особлива важливiсть перевiрки при критичних ситуацiях визнача¹ться небезпекою прояву помилок при функцiонуваннi програмного забезпечення в реальних умовах. Тому при тестуваннi активно застосовуються iмiтатори зовнiшнього середовища, що автоматично готують вхiднi данi, i засоби контролю, якi реагують на аномальнi результати виконання програм, вiд яких залежить безпека.

Тестування коректностi використання ресурсiв пам'я- тi та продуктивностi обчислювально¨ системи служать для оцiнки безпеки виконання програм при перевантаженнях пам'ятi та продуктивностi. Тестування здiйсню¹ться в основному у стохасти- чному режимi в реальному часi за пiдготовленими сценарiями, що створюють перевантаження одного з ресурсiв системи. Звичайно найбiльш повно тестуються буфернi нагромаджувачi приймання та видавання зовнiшнiм абонентам, а також використання масивiв у базi даних. Перевiрцi пiдляга¹ змiна якостi, надiйностi та безпеки функцiонування системи внаслiдок пропускiв в обробленнi повiдомлень, зростання тривалостi очiкування ¨х перед обробленням або розтягування перiодiв розв'язання задач. Iмiтацiя тестiв здiйсню¹ться в основному автоматично за сценарiями, що створюють критичнi умови для певно¨ перевiрки. У результатi тестування встановлюються реальнi характеристики iнформацiйно¨ системи на вибранiй обчислювальнiй системi за пропускною здатнiстю розв'язання усього комплексу задач, а також за допустимою iнтенсивнiстю розв'язку окремих типiв задач та оброблення рiзноманiтних повiдомлень. При короткочасних перевантаженнях пам'ятi

або продуктивностi повинен забезпечуватися захист вiд вiдмов та вiдновлення нормального режиму при наступному зниженнi завантаження.

Тестування паралельного виконання програм використову¹ться для виявлення пониження надiйностi та безпеки, зумовлених неузгодженим використанням вхiдних та промiжних даних, а також пристро¨в обчислювально¨ системи при паралельному виконаннi програм. Тестування здiйсню¹ться переважно стохастично з основним завданням здiйснити перевiрку при рiзноманiтних сполученнях виконання частин програми процесорами, що функцiонують одночасно. Особливо важливо виявити усi тупиковi ситуацi¨. Мала ймовiрнiсть виникнення таких ситуацiй може призвести до необхiдностi генерацi¨ великого обсягу стохастичних тестiв. Тестування паралельно виконуваних програм звичайно потребу¹ велико¨ кiлькостi вхiдних даних, що мiстять як випадковi, так i детермiнованi складовi. Такi данi готуються в основному автоматично за сценарiями найбiльш критичних сполучень даних.

Тестування ефективностi захисту вiд спотворень вхiдних даних служить для виявлення помилок у програмах, що проявляються при складних або спотворених даних. Тестування проводиться при вiдносно невеликих спотвореннях вхiдних даних, що вiдповiдають нормованому зростанню в них помилок. А також при випадковому повному спотворенню даних. Доцiльно вимiрювати ймовiрностi появи спотворень та iншi характеристики. При тестуваннi виявляються ситуацi¨ порушення працездатностi системи та величини зниження безпеки ¨¨ функцiонування залежно вiд iнтенсивностi спотворень. Спотворення даних здiйснюються в основному стохастично, проте у деяких випадках можуть бути необхiдними детермiнованi та корельовано спотворення рiзноманiтних даних.

Тестування для оцiнки ефективностi захисту вiд збо- ¨в апаратури та невиявлених помилок програм i даних служить для перевiрки якостi програмного контролю та оперативного вiдновлення (рестарту) при рiзноманiтних ненавмисних спотвореннях функцiонування програмного забезпечення. Стохастичне тестування засобiв рестарту здiйсню¹ться у процесi визначення показникiв надiйностi функцiонування програм. При цьому оцiню-

ються ймовiрнiсть виявлення ситуацi¨ вiдмови та середня тривалiсть вiдновлення нормального функцiонування. Спецiалiзований тест оцiнки ефективностi захисту дозволя¹ визначити ймовiрнiсть виявлення кожного виду збо¨в та вiдповiдну йому тривалiсть вiдновлення нормального функцiонування. Для цього розроблюються сценарi¨ iмiтацi¨ апаратних збо¨в, спотворень вхiдних даних та програмних помилок, що викликають спрацьовування засобiв програмного контролю та оперативного вiдновлення. Таким чином виявляються помилки програм контролю та програм вiдновлення, а також визначаються ¨х динамiчнi характеристики. Складнiсть даного виду тестування визнача¹ться труднощами регламентованого введення збо¨в обчислювальних систем та складнiстю iмiтацi¨ прояву помилок у розроблених програмах. Окрiм того, внаслiдок нечастих подiй ситуацiй вiдмов для статистичних оцiнок необхiдне штучне пiдвищення iнтенсивностi ¨х виникнення.

Тестування для вимiрювання досягнутих значень надiйностi та безпеки базових версiй iнформацiйних систем призначене для визначення основних показникiв надiйностi та безпеки при реальному функцiонуваннi програм. У процесi тестування при типових та критичних умовах визначаються значення напрацювання на вiдмову, тривалiсть вiдновлення, коефiцi¹нта готовностi та iнших показникiв. Для складних систем реального часу органiзовуються багаточасовi прогони iнформацiйних системи при стохастичних вхiдних даних, при яких ре¹струються спотворення результатiв та видiляються порушення працездатностi програм. При такому тестуваннi особливе значення ма¹ спiввiдношення типових та критичних умов функцiонування та вхiдних даних. Це спiввiдношення повинне встановлюватися вiдповiдно до технiчного завдання на iнформацiйну систему та формалiзуватися в методицi тестування за узгодженням мiж розробником та замовником. Для систем з високими показниками надiйностi можуть застосовуватися форсованi методи тестування. При яких штучно пiдвищу¹ться iнтенсивнiсть спотворень вхiдних даних, вводяться часковi вiдмови та пiдвищенi рiвнi збо¨в у апаратурi. Значення надiйностi при форсованих випробовуваннях потiм повинно коректно перераховуватися на нормальнi умови експлуатацi¨. Iмiтацiя вхiдних даних та ре¹страцiя вiдмов може здiйснюватися автоматично, при

цьому особливо важливо забезпечити ре¹страцiю умов порушення працездатностi.

Тестування зручностi експлуатацi¨ та вза¹модi¨ людини з iнформацiйною системою призначене для виявлення помилок подання вхiдних та результативних даних, якi важко формалiзувати. При тестуваннi оцiнюються обсяг, зручнiсть представлення та контролю вхiдних даних. Що вводяться безпосередньо людиноюкористувачем, а також вiдображуваних результуючих даних, зру- чнiсть ¨х аналiзу те безпека використання. Крiм того перевiряються динамiчнi характеристики введення там вiдображення даних у реальному часi. В складних автоматизованих системах управлiння, в яких основнi данi поступають каналами зв'язку. Велике зна- чення ма¹ тестування прийняття рiшень людиною в динамiцi функцiонування системи, особливо у критичних ситуацiях. Тестування дозволя¹ виявляти помилки розподiлу функцiй мiж людиною та ЕОМ, а також оцiнити можливiсть безпечного виконання завдань обслуговуючим персоналом системи. Частина перевiрок, зв'язана з оцiнкою зручностi використання документацi¨. Може виконуватися без обчислювально¨ системи, шляхом порiвняння цiлей та дiй людини iз змiстом користувальницько¨ документацi¨. При оцiнцi психологiчно¨ зручностi експлуатацi¨ велике значення може мати вибiр представлено¨ групи операторiв-користувачiв. х квалiфiкацiя, критичнiсть та доброзичливiсть можуть сильно змiнювати результати випробувань.

Тестування зручностi та якостi пiдготовки користу-

вальницьких версiй iнформацiйно¨ системи служить для виявлення помилок методiв та засобiв настройки базових версiй системи до конкретних умов застосування. Багато систем перед використанням адаптуються до операцiйного середовища або до конкретних умов. При яких повиннi розв'язуватися задачi. Для цього можуть автоматизованим чином готуватися данi, що характеризують цi умови. Тестування переслiду¹ цiль перевiрки та виявлення помилок засобiв настройки, а також безпеки функцiонування адаптованих до рiзних умов версiй iнформацiйно¨ системи. Для перевiрки засобiв адаптацi¨ створюються спецiальнi тести, що охоплюють найбiльш типовi режими використання системи користувачами. Тестування адаптованих версiй може здiйснювати на базi

тестiв випробувань на вiдповiднiсть до технiчного завдання, дороблених за спецiальною методикою для перевiрки адаптацi¨.

Тестування роботи базових версiй iнформацiйно¨ системи при конфiгурацiях обладнання використову¹ться для виявлення помилок, що проявляються при змiнi складу або характеристик компонент обчислювально¨ системи або зовнiшнього середовища. Програмне забезпечення, що випуска¹ться серiйно та широко застосову¹ться, може функцiонувати на обчислювальних системах, що розрiзняються складом обладнання або при¹днанням зовнiшнiх абонентiв та ¨х характеристиками. Число можливих конфiгурацiй обладнання може бути надзвичайно великим, щоб всiх ¨х протестувати при пiдготовцi базово¨ версi¨ системи. Тому важливе зна- чення ма¹ методика та засоби пiдготовки iнформацiйно¨ системи до рiзноманiтних конфiгурацiй обладнання. До складу базово¨ версi¨ вводяться засоби, що дозволяють адаптувати ¨х до таких змiн обладнання. Тести повиннi забезпечувати перевiрку цих засобiв автоматично¨ адаптацi¨ в усiх допустимих режимах комплектування обладнання, а також випробування безпеки адаптованих версiй. Для цього розроблю¹ться методика пiдготовки тестiв перевiрки адаптовано¨ версi¨ користувачiв, яка використову¹ться настроюва- чами версiй.

Як правило, при тестуваннi необхiдно використати iмiтатори реального зовнiшнього середовища . У таких випадках (випробування систем управлiння повiтряним рухом, польотом лiтакiв та космiчних кораблiв, великих банкiвських систем) вимоги до засобiв забезпечення випробувань технологiчно¨ безпеки iнформацiйно¨ системи зводиться до наступних положень:

•усi данi вiд реальних об'¹ктiв i iмiтаторiв зовнiшнього сере-

довища повиннi поступати iнформацiйну систему, що пiдляга¹ випробуванню, вiдповiдно до природного ходу процесiв в цих об'¹ктах реального часу;

•дiапазони змiни вхiдних даних в iмiтаторах повиннi забезпе-

чувати перекриття усiх характеристик сучасних реальних об'¹- ктiв зовнiшнього середовища, а також передбачати можливiсть ¨х розширення з урахуванням передбачуваного розвитку iнформацiйно¨ системи та прогресу у вiдповiдних галузях технiки;

•необхiдно сполучати данi вiд реальних об'¹ктiв зовнiшнього се-

редовища та вiд iмiтаторiв, що замiнюють деякi з них, якi нерацiонально або неможливо застосовувати при випробуваннях

у натуральному виглядi;

•необхiдно забезпечити ре¹страцiю, контроль та узагальнення

характеристик генерованих тестових даних, еталонних даних та усiх видiв спотворень та аномалiй, що поступають на iнформацiйну систему, що пiдляга¹ випробуванню, у будь-який момент часу i на будь-якому кроцi оброблення iнформацi¨;

•при формуваннi тестових даних вiд ряду об'¹ктiв повиннi опе-

ративно враховуватися впливи результатiв функцiонування системи, що пiдляга¹ випробуванню, за даним, що поступили ранiше, вiд тих же об'¹ктiв з урахуванням зворотних iнформацiйних та управляючих зв'язкiв;

•для всiх тестових даних повиннi бути пiдготовленi еталоннi ре-

акцi¨ iнформацiйно¨ системи, з якими слiд порiвнювати результати, якi одержують у процесi випробувань;

•необхiдно забезпечити вимiрювання та узагальнення показни-

кiв якостi та безпеки iнформацiйно¨ системи за результатами проведення сеансiв випробувань з певними цiльовими завданнями;

•слiд забезпечити максимально можливу повторюванiсть сеан-

сiв випробувань та генерованих тестiв пiсля виявлення та усунення дефектiв у функцiонуваннi iнформацiйно¨ системи. Перелiченi вимоги визначають необхiднiсть розробки вiдповiд-

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

Труднощi адекватного моделювання деяких об'¹ктiв зовнiшнього середовища, особливо якщо в ¨х функцiонуваннi активно бере участь оператор-користувач, не дозволя¹ зосередити та повнiстю автоматизувати всю iмiтацiю тестових даних ЕОМ. Тому для реалiзацi¨ iнтегрованих проблемно-орi¹нтованих систем забезпече-

ння випробувань безпеки складних систем необхiднi аналоги реальних об'¹ктiв зовнiшнього середовища для формування частини даних, а також ресурси обчислювальних засобiв для iмiтацi¨ даних вiд решти об'¹ктiв. Розумне сполучення частини реальних об'¹ктiв зовнiшнього середовища та iмiтаторiв на ЕОМ дозволя¹ створити високоефективнi моделюючi випробувальнi стенди з комплексними моделями сукупностi об'¹ктiв, необхiдних для випробувань безпеки складних iнформацiйних систем у реальному часi. Такi стенди дозволяють автоматизовану генерацiю стендiв за допомогою iмiтаторiв на ЕОМ та аналогiв реально¨ апаратури доповнювати реальними даними вiд операторiв-користувачiв, що контролюють та коректують функцi¨ функцiонування системи оброблення iнформацi¨. В схемi типового стенду можна видiлити ряд базових компонент та процесiв (рис. 4.3).

Важливою функцi¹ю випробувальних стендiв ¹ ¨х використання у якостi тренажерiв для операторiв користувачiв. Так як якiсть та безпека функцiонування системи може сутт¹во залежати вiд характеристик конкретно¨ людини, що бере участь у обробленнi iнформацi¨, то необхiдно вимiрювати цi характеристики. Крам того, необхiдно мати можливiсть покращувати ¨х до рiвня, що забезпе- чу¹ виконання заданих вимог до системи. Тому в процес випробувань iнформацiйно¨ системи органiчно входить процес тренування та вимiрювання характеристик реально¨ реакцi¨ операторiв, а також використання стенду для регулярно¨ пiдготовки операторiвкористувачiв у процесi тиражування та експлуатацi¨ iнформацiйно¨ системи. Крiм того, випробувальний стенд може служити прототипом для розробки тренажерiв у серiйних системах управлiння та оброблення iнформацi¨.

4.3Забезпечення гарантiй виконання полiтики безпеки на основi методу генерацi¨ iзольованих програмних середовищ

4.3.1Спiввiдношення гарантiй виконання полiтики безпеки с поняттям iзольованого програмного середовища

4.3.1.1.Забезпечення гарантiй виконання полiтики безпеки на основi iзольованостi комп'ютерно¨ системи

Розглянемо забезпечення гарантiй виконання полiтики безпеки на основi аналiзу можливих шляхiв ¨¨ порушення (рис. 4.4).

Ðèñ. 4.4. Можливi шляхи порушення полiтики безпеки

Очевидно, що при змiнi об'¹ктiв (АО), якi функцiонально асоцiйованi з суб'¹ктом реалiзацi¨ полiтики безпеки, що визначаються монiтором безпеки об'¹кта (МБО), можуть змiнюватися i властивостi самого монiтора безпеки об'¹кта, що полягають у фiльтрацi¨ потокiв, i як наслiдок можуть виникати потоки, що належать

до заборонених потокiв множини N. У зв'язку з цим вводиться поняття коректностi суб'¹ктiв.

Ïàðà ñóá'¹êòiâ Si i Sj називаються такими, що не впливають

один на одного (або коректними вiдносно один одного), якщо у будь-який момент часу вiдсутнiй потiк (що змiню¹ стан об'¹кта)

мiж асоцiйованим об'¹ктом суб'¹кта Si(Osi) i Sj(Osj), причому Osj не ¹ асоцiйованим об'¹ктом Si, à Osi не ¹ асоцiйованим об'¹ктом

Sj.

Можна дати наступне пояснення до визначення: змiна стану об'¹кта тракту¹ться в даному визначеннi як нетотожнiсть об'¹ктiв у вiдповiднi моменти часу, але при цьому пiдкреслю¹ться, що операцiя змiни об'¹кта локалiзована в суб'¹ктi, з яким цей об'¹кт не асоцiйований. Суть поняття коректностi поясню¹ться наступним чином: програми. що iснують в ¹диному просторi програмного забезпечення, не повиннi мати функцiональних можливостей для змiни чужого вектору коду та стану змiнних.

Бiльш жорстким визначенням може бути наступне. Пара суб'¹- êòiâ Si i Sj називаються такими, що абсолютно не впливають один

на одного (або абсолютно коректними вiдносно один одного, якщо в умовах попереднього визначення множини асоцiйованих об'¹ктiв не перетинаються.

Абсолютна коректнiсть легко досяга¹ться у випадку вiртуального адресного простору.

Визначення абсолютно¨ коректностi дозволя¹ сформулювати достатнi умови гарантованого здiйснення тiльки дозволеного доступу.

Твердження 1 або достатня умова гарантованого виконання полiтики безпеки в комп'ютернiй системi . Монiтор безпеки об'¹- ктiв дозволя¹ породження потокiв тiльки з дозволено¨ множини L,

якщо усi iснуючi в системi суб'¹кти абсолютно коректнi вiдносно нього та один одного.

Доведення. Умова абсолютно¨ коректностi (жорстким визначе- нням) передбача¹ незмiннiсть функцiонально асоцiйованих об'¹- ктiв монiтора безпеки об'¹ктiв (оскiльки потокiв, що змiнюють асоцiйованi об'¹кти монiтора безпеки об'¹ктiв, не iсну¹). З iншо¨ сторони, такi потоки можуть з'явитися при змiнi асоцiйованих об'¹ктiв, що належать iншим суб'¹ктам комп'ютерно¨ системи (змiнюються властивостi суб'¹кта, у тому числi (можливо) i з породження потокiв до монiтора безпеки об'¹ктiв.). Умова коректностi суб'¹ктiв

вiдносно одни одного роблять це неможливим (за визначенням абсолютно¨ коректностi). Це у свою чергу, означа¹, що монiтор без-

пеки об'¹ктiв реалiзу¹ тiльки потоки з множини L. Твердження

доведене.

Проте сформульоване твердження наклада¹ вельми жорсткi та важкорозв'язнi умови на властивостi суб'¹ктiв в комп'ютернiй системi. Крiм того, неможливо гарантувати коректнiсть будь-якого суб'¹кта, що активiзу¹ться в комп'ютернiй системi, вiдносно монiтора безпеки суб'¹ктiв. У зв'язку з цим логiчно обмежити множину породжуваних суб'¹ктiв, якi апрiорно коректнi вiдносно монiтора безпеки об'¹ктiв. У зв'язку з цим можна ввести визначення монiтора породження суб'¹ктiв (за аналогi¹ю з монiтором звернень) та монiтора безпеки суб'¹ктiв.

Монiтор породження суб'¹ктiв це суб'¹кт, що активiзу¹ться при будь-якому породженнi суб'¹ктiв.

За аналогi¹ю з переходом вiд монiтора звернень до монiтора безпеки об'¹ктiв можна ввести поняття монiтора безпеки суб'¹ктiв.

Монiтор безпеки суб'¹ктiв це суб'¹кт, який дозволя¹ породження суб'¹ктiв тiльки для фiксовано¨ пiдмножини пар суб'¹ктiв, що активiзуються, i об'¹ктiв. що породжуються.

Вплив монiтора безпеки суб'¹ктiв видiля¹ в усiй множинi суб'¹- ктiв S пiдмножину дозволених E. Звичайно зазначають, що якщо

у пiдмножинi суб'¹ктiв у момент часу t включа¹ться суб'¹кт мо-

нiтора безпеки суб'¹ктiв, то першим аргументом операцi¨ create може бути тiльки суб'¹кт, що входить до множини суб'¹ктiв. а аргумент будь-який об'¹кт.

Можна також сформулювати тепер ряд базових визначень якi у подальшому можна використати.

Комп'ютерна система назива¹ться замкнутою з породження су- б'¹ктiв, якщо в нiй дi¹ монiтор безпеки суб'¹ктiв, що дозволя¹ породження тiльки фiксовано¨ скiнченно¨ пiдмножини суб'¹ктiв для будь-яких об'¹ктiв-джерел, що розглядаються для фiксовано¨ декомпозицi¨ комп'ютерно¨ системи на суб'¹кти та об'¹кти.

При розглядi питань реалiзацi¨ захищених середовищ буде використовуватися термiн захищене програмне середовище , який по сутi ¹ еквiвалентним наведеному вище визначенню.

Проте замкнутостi комп'ютерно¨ системи з породження суб'¹-

ктiв недостатньо для опису властивостей системи у частинi захищеностi, оскiльки необхiдно забезпечити коректнiсть породжуваних монiтором безпеки суб'¹ктiв суб'¹ктiв вiдносно його самого та монiтора безпеки об'¹ктiв. Механiзм замкнутого програмного середовища скорочу¹ множину можливих суб'¹ктiв до деяко¨ множини фiксовано¨ потужностi, але при цьому припуска¹ iснування некоректних суб'¹ктiв, включених у замкнуте середовище.

Сформулю¹мо визначення iзольованостi комп'ютерно¨ системи. Множина суб'¹ктiв комп'ютерно¨ системи назива¹ться iзольованою (абсолютно iзольованою), якщо в нiй дi¹ монiтор безпеки суб'¹ктiв та суб'¹кти з породжувано¨ множини коректнi (абсолютно коректнi) вiдносно один одного та монiтора безпеки суб'¹ктiв. Виходячи з визначення iзольованостi комп'ютерно¨ системи мо-

жна сформулювати два основнi наслiдки:

•áóäü-ÿêà пiдмножина суб'¹ктiв iзольовано¨ (абсолютно iзольо-

вано¨) комп'ютерно¨ системи, що включа¹ монiтор безпеки су- б'¹ктiв, також склада¹ iзольоване (абсолютно iзольоване) середовище;

•доповнення iзольовано¨ (абсолютно iзольовано¨) комп'ютерно¨

системи суб'¹ктом, коректним (абсолютно коректним) вiдносно будь-якого з числа тих, що входять до iзольованого (абсолютно iзольованого) середовища, залишають його iзольованим (абсолютно iзольованим).

Тепер можна переформулювати достатню умову гарантованого виконання полiтики безпеки наступним чином.

Твердження 2 або достатня умова гарантованого виконання полiтики безпеки в комп'ютернiй системi . Якщо в абсолютно iзольованiй комп'ютернiй системi iсну¹ монiтор безпеки об'¹ктiв та породжуванi суб'¹кти абсолютно коректнi вiдносно монiтора безпеки об'¹ктiв. а також монiтор безпеки суб'¹ктiв абсолютно коректний вiдносно монiтора безпеки об'¹ктiв, то у такiй комп'ютернiй системi реалiзу¹ться тiльки доступ, описаний в правилах розмежування доступу.

Доведення. З доведення абсолютно¨ iзольованостi виходить можливiсть iснування в комп'ютернiй системi тiльки скiнченно¨ множини суб'¹ктiв, якi, у свою чергу, коректнi вiдносно монiтора безпеки суб'¹ктiв.

Дальше за умовою твердження (коректнiсть монiтора безпеки об'¹ктiв вiдносно будь-якого з породжуваних суб'¹ктiв i монiтора безпеки суб'¹ктiв) асоцiйованi об'¹кти можуть змiнюватися тiльки самим монiтором безпеки об'¹ктiв, отже, в комп'ютернiй системi

реалiзуються тiльки потоки, що належать множинi L. Твердження

доведене.

Легко бачити, що дане твердження ¹ бiльш конструктивним вiдносно попередньо¨ достатньо¨ умови гарантовано¨ захищеностi, оскiльки ранiше вимагалася коректнiсть монiтора безпеки об'¹ктiв вiдносно довiльного суб'¹кта, що практично ¹ неможливим. У даному ж випадку множина суб'¹ктiв обмежена за рахунок застосування механiзму монiтора безпеки суб'¹ктiв i ¹ можливiсть упевнитися у попарнiй коректностi породжуваних суб'¹ктiв.

4.3.1.2. Поняття iзольованого програмного середовища

При розглядi технiчно¨ реалiзацi¨ iзольованостi суб'¹ктiв в ком- п'ютернiй системi застосову¹ться термiн iзольоване програмне середовище (IПС), який опису¹ механiзм реалiзацi¨ iзольованостi для конкретно¨ програмно-апаратно¨ реалiзацi¨ комп'ютерно¨ системи i при вiдповiднiй декомпозицi¨ на суб'¹кти та об'¹кти.

При розглядi операцi¨ породження суб'¹кта виника¹ вельми важлива проблема, повязана з тим, що в реальних комп'ютерних системах однаково пойменованi об'¹кти можуть мати рiзнi стани у просторi (наприклад, можуть бути розташованими в рiзних каталогах) або у часi.

Припустимо, що зафiксований стан об'¹кта Om у деякий мо- ìåíò ÷àñó t0. Будемо позначати стан об'¹кта Om у момент часу t ÿê Om[t].

Операцiя породження суб'¹кта create(Sk, Om) → Si назива- ¹ться породженням з контролем незмiнностi об'¹кта, якщо для будь-якого моменту часу t > t0, в який активiзована операцiя

породження create, породження суб'¹кта Si можлива тiльки про тотожностi об'¹ктiв Om[t0] i Om[t].

При даних умовах породженi суб'¹кти Si[t1] i Si[t2] ¹ тотожни-

ìè, ÿêùî t1 > t0 i t2 > t0. Ïðè t1 = t2 породжу¹ться один i той же суб'¹кт. При породженнi суб'¹ктiв з контролем незмiнностi об'¹кта

в комп'ютернiй системi допустимi потоки вiд суб'¹ктiв до об'¹ктiвджерел, що беруть участь в породженнi суб'¹ктiв, iз змiною ¨х стану

Твердження 3 або базова теорема iзольованого програмного простору формулю¹ться наступним чином [31]. Якщо у момент

÷àñó t0 в iзольованiй комп'ютернiй системi дi¹ тiльки породження

суб'¹ктiв з контролем незмiнностi об'¹кта та iснують потоки вiд будь-якого суб'¹кта до будь-якого об'¹кта, що не суперечить умовi коректностi (абсолютно¨ коректностi) суб'¹ктiв, то ц будь-який

момент часу t > t0 комп'ютерна система залиша¹ться iзольованою

(абсолютно iзольованою).

Доведення теореми. За умовою твердження в комп'ютернiй системi ¹ можливим iснування потокiв, що змiнюють стан об'¹ктiв, не асоцiйованих у цей момент часу з будь-яким суб'¹ктом. Якщо об'¹кт iз змiненим станом не ¹ джерелом для породження суб'¹- кта, то множина суб'¹ктiв iзольованого середовища не ¹ розширюваною, у протилежному випадку (змiнюваний об'¹кт ¹ джерелом для породження суб'¹кта) за умовами твердження (породження суб'¹кта з контролем) породження суб'¹кта ¹ неможливим. Отже, потужнiсть множини суб'¹ктiв не може перевищувати тi¹¨, яка була зафiксована до змiни стану будь-якого об'¹кта. Вiдповiдно до наслiдку з визначення операцi¨ породження суб'¹кта з контролем незмiнностi об'¹кта (про замкнутiсть множини суб'¹ктiв в iзольованому програмному просторi з незростаючою потужнiстю множини суб'¹ктiв) одержимо, що множина суб'¹ктiв комп'ютерно¨ системи ¹ iзольованою. Твердження доведене.

Можна сформулювати методологiю проектування гарантовано захищених комп'ютерних систем. Сутнiсть дано¨ методологi¨ поляга¹ у тому, що при проектуваннi захисних механiзмiв комп'ю- терно¨ системи необхiдно опиратися на сукупнiсть достатнiх умов, якi повиннi бути реалiзованi для суб'¹ктiв, що гарантують захиснi властивостi, визначенi для реалiзацi¨ монiтора безпеки об'¹ктiв в комп'ютернiй системi (тобто гарантоване виконання задано¨ монiтором безпеки об'¹кта полiтики безпеки).

Концепцiю iзольованого програмного середовища звичайно розглядають як розширення пiдходiв до реалiзацi¨ ядра безпеки.

Модель функцiонування ядра безпеки вiдобража¹ться у вигля-

дi наступно¨ схеми, представлено¨ на рис. 4.5.

Ðèñ. 4.5. Класична модель ядра безпеки

Íà ðèñ. 4.5 база даних захисту означа¹ об'¹кт, що мiстить у собi iнформацiю про потоки множини L (захист за бiлим спи-

ском дозволи на потоки) або N (захист за чорним списком

заборону на потоки).

Для урахування впливу суб'¹ктiв в комп'ютернiй системi необхiдно розглядати розширену схему вза¹модi¨ елементiв системи реалiзацi¨ та гарантування полiтики безпеки.

Íà ðèñ. 4.6 пiдкреслена роль монiтора безпеки суб'¹ктiв при породженнi об'¹ктiв. Вза¹модiя суб'¹ктiв та об'¹ктiв при породженнi потокiв уточнена введенням асоцiйованих з суб'¹ктом об'¹ктiв. Конструкцiя ОУ на схемi означа¹ об'¹кт управлiння, тобто об'- ¹кт, що мiстить iнформацiю про дозволенi значення вiдображення

stream (про елементи множини L àáî N i create (елементи множини E). Об'¹кт управлiння може бути асоцiйованим (асоцiйова-

ний об'¹кт-данi) як з монiтором безпеки об'¹ктiв, так iз монiтором безпеки суб'¹ктiв.

Тепер можна перейти до опису практичних методiв побудови iзольованого програмного середовища. Метою розгляду ¹ iлюстрацiя твердження про те, що достатнi умови гарантовано¨ захищеностi можуть бути практично виконанi в реальних комп'ютерних системах

Ðèñ. 4.6. Ядро безпеки з урахуванням контролю породження су- б'¹ктiв

4.3.2Метод генерацi¨ iзольованого програмного середовища при проектуваннi механiзмiв гарантовано¨ пiдтримки полiтики безпеки

Опираючись на базову теорему iзольованого програмного середовища можна описати метод суб'¹ктно-об'¹ктно¨ вза¹модi¨ в рамках iзольованого програмного середовища для бiльш конкретно¨ архiтектури комп'ютерно¨ системи.

З твердження 3 виходить, що для створення гарантовано захищено¨ комп'ютерно¨ системи (стосовно виконання задано¨ полiтики безпеки) необхiдно:

1.Упевнитися у попарнiй коректностi суб'¹ктiв, що входять до iзольованого програмного середовища (або впевнитися у коректностi будь-якого суб'¹кта вiдносно монiтора безпеки суб'¹ктiв та монiтора безпеки об'¹ктiв).

2.Спроектувати або реалiзувати програмно (або програмноапаратно) монiтор безпеки суб'¹ктiв так, щоб:

•äëÿ будь-якого суб'¹кта та будь-якого об'¹кта здiйснювався би контроль породження суб'¹ктiв (тобто, щоб реалiзацiя монiтора

безпеки суб'¹ктiв вiдповiдала його визначенню);

•породження будь-якого суб'¹кта вiдбувалося би з контролем

незмiнностi об'¹кта-джерела.

3. Реалiзувати монiтор безпеки об'¹ктiв в рамках апрiорно сформульовано¨ полiтики безпеки.

Треба вiдзначити, що наведенi вище твердження ¹ вiрними тiльки тодi, коли описана та реалiзована полiтика безпеки не порушу¹ ¨х умов (перевiрка даного факту залежить вiд моделi полiтики безпеки та ¹ окремим вельми важливим завдання).

Крiм того, необхiдно звернути увагу на наступне. Об'¹кт управлiння, який ¹ асоцiйованим об'¹ктом монiтора безпеки суб'¹ктiв (звичайно асоцiйований об'¹кт-данi), вiдiгра¹ вирiшальну роль у проектуваннi iзольованого програмного середовища. При можливостi змiни стану об'¹кта управлiння потенцiйно можливе розмикання програмного середовища, тобто додавання до множини дозволених суб'¹ктiв додаткових, якi реалiзують зловмиснi функцi¨.

Çiншо¨ сторони, процес управлiння безпекою припуска¹ можливiсть змiни об'¹кта. Можливiсть змiни стану об'¹кта управлiння (реалiзацiя потоку stream) повинна бути присутньою для видiлених суб'¹ктiв (можливо з додатковими умовами активiзацi¨ цього суб'¹кта видiленим користувачем або користувачами).

Важливу роль при проектуваннi iзольованого програмного середовища вiдiгра¹ властивiсть комп'ютерно¨ системи, що поляга¹ у поетапнiй активiзацi¨ суб'¹ктiв iз об'¹ктiв рiзного рiвня представлення iнформацi¨. У табл. 4.1 можна розглянути i¹рархiю рiвнiв при завантаженнi операцiйно¨ системи.

Óтаблицi видiлений термiн сектор для позначення представлення об'¹кта апаратно-програмного рiвня. Вiн познача¹ безперервну послiдовнiсть елементiв зберiгання (байт) на матерiальному носi¨, що характеризу¹ться мiсцем знаходження.

Термiн файл познача¹ абстрактний об'¹кт, побудований за облiковою структурою з об'¹ктiв сектор . Об'¹кти типу файл iсектор видiленi виключно виходячи з типово¨ структури об'¹ктiв комп'ютерно¨ системи.

Óзагальному виглядi можна говорити про рекурсивну структуру об'¹ктiв деякого рiвня, що вмiщують об'¹кти попереднього рiвня. На нульовому рiвнi первинний об'¹кт (елементарна структу-

Òàáë. 4.1 I¹рархiя рiвнiв при завантаженнi операцiйно¨ системи

ра нижнього рiвня) в табл. 4.1 вiдповiдають термiну сектор .

З урахуванням i¹рархiчно¨ структури представлення об'¹ктiв можна говорити про те, що у початковi етапи активiзацi¨ ком- п'ютерно¨ системи декомпозицiя на об'¹кти та суб'¹кти динамiчно змiню¹ться. Отже, основна теорема iзольованого програмного простору може бути застосовною тiльки на окремих iнтервалах часу, коли рiвень представлення об'¹ктiв постiйний а декомпозицiя фiксована. Можна стверджувати, що iзольований програмний простiр, який дi¹ вiд моменту активiзацi¨ до моменту закiнчення роботи комп'ютерно¨ системи, неможливо сформувати у початковий момент активiзацi¨ комп'ютерно¨ системи.

Нехай у комп'ютернiй системi вiддiля¹ться скiнченне число рiвнiв представлення об'¹ктiв U = {0, ..., R}, äå R максимальний

рiвень представлення об'¹ктiв.

З точки зору виконання умов твердження 3 мало би смисл говорити про деякий стацiонарний стан комп'ютерно¨ системи, коли у вiдображеннях stream i create беруть участь тiльки об'¹кти

ðiâíÿ R. Тодi реалiзацiя монiтора безпеки суб'¹ктiв може бути зна-

чно спрощеною (у тому смислi, що усi аргументи-об'¹кти операцi¨ create мають такий же рiвень). Необхiдно звернути увагу на те, що така вимога, з однi¹¨ сторони, може накладати обмежувальну умови на властивостi прикладного програмного забезпечення (неможливiсть iнiцiювання потокiв, що включають об'¹кти рiвня

меншого за R, прикладними програмiстами), а з iншо¨ сторони,

бути наслiдком проектувальних рiшень реалiзацi¨ суб'¹кта, локалiзованого в ядрi операцiйно¨ системи (прикладом ¹ операцiйна система Windows NT 4.0, що забороня¹ операцi¨ вище рiвня файл зi сторони суб'¹ктiв прикладного рiвня).

Практична реалiзацiя усiх операцiйних систем дозволя¹ видiлити двi фази ¨х роботи:

•активiзацiя суб'¹ктiв з ростом рiвня представлення об'¹ктiв (фаза завантаження або початкова фаза);

•фаза стацiонарного стану (коли рiвень представлення об'¹ктiв не збiльшу¹ться).

Звичайно, необхiдно зробити застереження, що стосу¹ться можливостi реалiзацi¨ потокiв до об'¹ктiв нижнього рiвня (операцiйнi системи типу DOS, в яких можлива операцiя з будь-яким об'¹ктом нижнього рiвня (сектор) з програми прикладного рiвня).

Тодi практична реалiзацiя iзольованого програмного простору може складатися з двох етапiв:

•напередвизначення виконання початково¨ фази, що включа¹ у

собi момент активiзацi¨ монiтора безпеки суб'¹ктiв (i монiтора безпеки об'¹ктiв);

•робота в стацiонарнiй фазi в режимi iзольованого програмного

простору (можливо, з контролем незмiнностi об'¹ктiв-джерел). Тут звичайно вводять поняття послiдовностi активiзацi¨ компонент комп'ютерно¨ системи. Смисл введених понять та сформульованих нижче тверджень поляга¹ у необхiдностi приведення су- б'¹ктiв комп'ютерно¨ системи в один i той же стан пiсля активiзацi¨ первинного суб'¹кта програмно-апаратного рiвня, або, iнакше кажучи, у завданнi напередвизначено¨ послiдовностi активiзацi¨ су-

б'¹ктiв комп'ютерно¨ системи.

Позначимо, що ZL ïîñëiäîâíiñòü ïàð (i, j)t (t = 0, 1, 2, ..., l−1моменти часу) довжини l, òàêi, ùî create(Si, Oj[t] → Sm[t + 1].

Позначимо також:

•SZ множина всiх суб'¹ктiв, включених до послiдовностi ZL;

•OZ множина всiх об'¹ктiв, включених до послiдовностi ZL.

Для багатопотокових комп'ютерних систем можна розглядати декiлька (можливо залежних один вiд одного) послiдовностей ZL i вiдповiдно множин SZ i OZ .

Визначимо, що станом комп'ютерно¨ системи у момент часу t

назива¹ться упорядкована сукупнiсть станiв об'¹ктiв, i, що кожний об'¹кт ¹ словом на апрiорно визначенiй мовi, а поняття стану су- б'¹кта сформульоване вище.

Твердження 4 або умова однакового стану комп'ютерно¨ системи. Стан комп'ютерно¨ системи у моменти часу t×1 i t×2 (t×1

i t × 2 обчислюються для двох вiдрiзкiв активностi комп'ютерно¨ системи вiд нульового моменту активiзацi¨ комп'ютерно¨ системи t01 i t02 (наприклад, вмикання живлення апаратурно¨ частини) однаково, якщо:

•t × 1 = t × 2;

•тотожнi суб'¹кти Si[t01] i Si[t02];

•незмiннi всi об'¹кти з множини ;

•íåçìiííà ïîñëiäîâíiñòü ZL.

Доведення за принципом математично¨ iндукцi¨. Вiрнiсть твердження при t = 1 виплива¹ з визначення тотожностi суб'¹- ктiв.

Нехай твердження ¹ вiрним для t = k < 1.

Тобi у момент часу k + 1 можуть бути породженими тiльки то-

тожнi суб'¹кти. Оскiльки тотожнi активiзуючi суб'¹кти (за припущенням iндукцi¨) i за умовою твердження ¹ незмiнними елементи

OZ

Довжина l послiдовностi Zl визнача¹ться:

•за ознакою неможливостi управлiння суб'¹ктами, що належать

множинi SZ , зi сторони користувача (у протилежному випадку послiдовнiсть активiзацi¨ суб'¹ктiв може бути змiненою);

•за ознакою доступностi для контролю незмiнностi усiх об'¹ктiв з множини OZ ;

•за ознакою незростання рiвня представлення iнформацi¨ (у даному випадку ма¹ться на увазi, що iсну¹ момент часу tx òà- кий, що для будь-якого t > tx об'¹кт-аргумент Oj операцi¨

stream(Si, Oj)t належить до одного рiвня представлення).

Необхiдно зазначити, що послiдовнiсть Zl локалiзу¹ться в де-

якому об'¹ктi або сукупностi об'¹ктiв (наприклад, для DOS послiдовнiсть активiзацi¨ суб'¹ктiв напередвизначена змiстом файлiв

autoexec.bat та con g.sys) i незмiннiсть послiдовностi Zl тотожна

незмiнностi вказаних об'¹ктiв, для операцiйно¨ системи Windows NT послiдовнiсть активiзацi¨ компонент визначена змiстом вiдповiдних ключiв ре¹стру (registry).

Нехай в послiдовностi Zl можна видiлити zi òàêå, ùî äëÿ áóäü- якого zk, k > i вiдображень create i stream використовують тiльки об'¹кти рiвня R. iншими словами, з моменту часу i наступа¹

стацiонарна фаза функцiонування комп'ютерно¨ системи.

За цих умов, а також при попарнiй коректностi суб'¹ктiв та дiй монiтора безпеки суб'¹ктiв з контролем незмiнностi об'¹ктiв-

джерел на рiвнi R з моменту часу m > k ¹ âiðíèì:

Твердження 5 або достатня умова iзольованостi програмного середовища при схiдчастому завантаженнi. За умови незмiнностi

Zl та незмiнностi об'¹ктiв з OZ в комп'ютернiй системi з моменту

часу встановлення незмiнностi Zl òà OZ дi¹ iзольоване програмне

середовище.

Доведення. Необхiдно зазначити. що всi умови твердження 5 вiдповiдають твердженню 4. уточнення стосуються структури по-

слiдовностi Zl.

Вiдповiдно до твердження 4 з моменту часу t = 0 до моменту

t = l дi¹ iзольоване (в рамках) SZ програмне середовище.

Для доведення твердження необхiдно переконатися у тому, що:

•монiтор безпеки суб'¹ктiв у момент часу t = m гарантовано активiзу¹ться;

•ó будь-який момент t > m програмне середовище ¹ iзольова-

íèì.

Перше виплива¹ з твердження 4 (при t = m стан програмно-

го середовища завжди буде однаковим, отже завжди буде активiзованим суб'¹кт монiтора безпеки суб'¹ктiв). Друге виплива¹ з визначення монiтора безпеки суб'¹ктiв та умови теореми.

Çмоменту часу t = 0 до моменту часу 1 програмне середовище

¹iзольованим, з моменту часу t > m програмне середовище також

¹iзольованим, отже комп'ютерна система ¹ iзольованою при будь-

якому t > 0. Твердження доведене.

Використовуючи твердження 3, 4 та 5, розглянемо процес практичного проектування захищеного фрагменту комп'ютерно¨ системи.

Спочатку необхiдно впевнитися у виконаннi умов коректностi або абсолютно¨ коректностi для суб'¹ктiв, що беруть участь у породження iзольованого програмного середовища. Указанi су- б'¹кти в основному можуть бути локалiзованi на рiвнi програмноапаратно¨ компоненти ЕОМ (програми постiйного запам'ятовую- чого пристрою, завантажувальники операцiйних середовищ), тобто працювати на рiвнi, що ¹ близьким до вза¹модi¨ з обладнанням комп'ютерно¨ системи, або на рiвнi операцiйного середовища. Доведення коректностi суб'¹ктiв програмно-апаратного рiвня значно вiдрiзня¹ться вiд вiдповiдних доведень для суб'¹ктiв прикладного рiвня. У зв'язку з цим можна видiлити перевiрку умов коректностi суб'¹ктiв у два кроки. Кроком 1 називають доведення коректностi суб'¹ктiв програмно-апаратного рiвня. Поняття модуль означа¹ реалiзацiю об'¹кта-джерела, а сукупнiсть суб'¹кта, породженого з об'¹кта-джерела та усi¹¨ множини асоцiйованих з цим суб'¹ктом об'¹ктiв протягом усього часу iснування суб'¹кта, що назива¹ться, як правило, процесом (або задачею, завданням).

Дальше необхiдно визначити склад програмних засобiв базового обчислювального середовища, тобто визначити конкретне операцiйне середовище, додатковi програмнi засоби сервiсу (наприклад, програмнi оболонки та засоби телекомунiкацiй) i програмнi засоби пiдтримки додаткового обладнання (програми управлiння принтером i т.iн.). Пiсля цього наступа¹ найбiльш трудомiсткий етап (Крок 2), на якому необхiдно впевнитися у коректностi су- б'¹ктiв описаного базового набору програмних засобiв. При цьому важливо вiдзначити наступне.

У складi програмного забезпечення комп'ютерно¨ системи не повинно бути цiлого класу можливостей якi можна назвати iнструментальними. Насамперед це можливiсть змiни стану асоцiйованих об'¹ктiв зi сторони суб'¹кта (наприклад, змiна вмiсту оперативно¨ пам'ятi), iнших суб'¹ктiв (змiна змiсту припуска¹ iснування операцiй stream типу запис), можливiсть iнiцiювання та припинення виконання процесiв нестандартним чином (окрiм механiзмiв

операцiйного середовища). Крiм того, при реалiзацi¨ монiтора безпеки суб'¹ктiв та монiтора безпеки об'¹ктiв на стацiонарнiй фазi функцiонування комп'ютерно¨ системи необхiдна вiдсутнiсть у будь-яких суб'¹ктах, замкнутих в iзольоване програмне середови-

ще. операцiй породження потокiв stream äî îá'¹êòiâ ðiâíÿ k > R.

У загальному виглядi достатнi умови до базового набору програмного забезпечення можна сформулювати наступним твердженням.

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

до об'¹ктiв логiчного рiвнi менше за R.

Легко бачити, що дане твердження ¹ зiбранi во¹дино умови виконання приведених вище тверджень.

Вимогу неможливостi припинення виконання суб'¹кта будьяким iншим чином, крiм призначеного пояснимо наступним чином. У даному випадку необхiдно враховувати, що у множинi суб'¹ктiв, замкнутих в iзольованому програмному просторi, два особливих випадки монiтор безпеки суб'¹ктiв i монiтор безпеки об'¹ктiв. припинення iснування монiтора безпеки суб'¹ктiв означа¹ порушення умови замкнутостi середовища, а припинення iснування монi-

тора безпеки суб'¹ктiв означа¹ допустимiсть потокiв множини N,

тобто несанкцiонований доступ.

Крок 3 поляга¹ у проектуваннi та розробцi програмних або програмно-апаратних засобiв захисту в комп'ютернiй системi, а потiм ¨хньому тестуваннi. Вiн припуска¹ проектування та реалiзацiю у заданiй множинi суб'¹ктiв монiтора безпеки суб'¹ктiв або монiтора безпеки об'¹ктiв.

Практичнi кроки 1 3 можуть бути виконанi виходячи з методик розробки та тестування програмного забезпечення.

Крок 4 поляга¹ у замиканнi всього комплексу програмного забезпечення, включаючи i засоби захисту, в iзольоване програмне середовище.

Отже, показано, що основними елементами пiдтримки iзольованостi програмного середовища ¹ контроль цiлiсностi та контроль породження процесiв.

Вище уже були сформульованi поняття монiтора безпеки суб'¹- ктiв та породження суб'¹ктiв з контролем ¨х незмiнностi. Необхiдно вiдзначити, що для достовiрного контролю незмiнностi об'¹кта (тобто з ймовiрнiстю помилки, що ¹ рiвною 0) необхiдно впевнитися у повнiй тотожностi об'¹кта, що перевiря¹ться, та зразка. З цього виходить, що еталон повинен мiстити не менше iнформацi¨, нiж об'¹кт, що пiдда¹ться перевiрцi. З цього у свою чергу виплива¹, що еталонний об¹кт повинен бути як мiнiмум однаково¨ довжини з тим. що перевiря¹ться. На практицi такий пiдхiд може бути застосованим iз серйозними обмеженнями (наприклад, для об'¹ктiв невеликого об'¹му типу програм постiйних запам'ятовуючих пристро¨в або завантажувальникiв операцiйних систем).

У зв'язку з цим для контролю цiлiсностi застосовують об'¹кти, що мiстять iнформацiю, яка не залежить вiд усього змiсту об'¹кта, але тим не менше значно меншого об'¹му, обчислену за допомогою класу функцiй типу геш-функцiй . Очевидно, що у цьому випадку процес встановлення незмiнностi об'¹кта ста¹ ймовiрнiсним.

Виходячи з даного факту неможливо говорити про гарантованi (детермiнованi) властивостi системи (оскiльки незмiннiсть об'¹кта гаранту¹ться лише з деякою ймовiрнiстю, що не ¹ рiвною 1). Отже, всi умови тверджень виконуються з деякою ймовiрнiстю. що залежить вiд властивостей геш-функцiй, що застосовуються для контролю цiлiсностi. Для пiдкреслювання умов, що змiнилися, дальше можна говорити не про контроль незмiнностi об'¹кта , à ïðî

контроль цiлiсностi об'¹кта .

Необхiдно також вiдзначити, що у процедурi контролю незмiнностi (яка тепер прийма¹ ймовiрнiсний характер) беруть участь мiнiмум два об'¹кти: об'¹кт контролю та еталонний об'¹кт (гешзначення), в також суб'¹кт, що реалiзу¹ геш-функцiю та здiйсню¹ порiвняння.

Тому для суб'¹кта контролю цiлiсностi важливим ¹ виконання

наступних умов:

•якiсний алгоритм контролю цiлiсностi (термiн якiсний буде пояснений нижче);

•контроль реальних даних (тобто вiдображення стану об'¹кта,

що пiдляга¹ контролю, та еталонного об'¹кта в асоцiйованi об'¹кти-данi суб'¹кта контролю цiлiсностi, що спiвпадають з тотожним).

Можна пояснити бiльш докладно другий пункт. Контроль цiлiсностi завжди сполучений з читанням даних (тобто з iнiцiюванням потокiв вiд об'¹ктiв до асоцiйованих об'¹ктiв-даних суб'¹кта контролю цiлiсностi, причому потоки можуть вiдповiдати рiзному рiвню представлення iнформацi¨ читання за секторами, читання за файлами i т.iн.). Наприклад, вбудований в BIOS ПЕОМ суб'¹кт (практично це програмна закладка) може нав'язувати при читаннi замiсть одного сектора iнший або редагувати безпосередньо буфер, у який були прочитанi данi. Аналогiчний ефект може бути викликаний суб'¹ктами операцiйного середовища, наприклад, су- б'¹ктами, що локалiзованi в первинних завантажниках операцiйно¨ системи. З iншо¨ сторони, навiть контроль BIOS може здiйснюватися пiд спостереженням будь-яко¨ додатково¨ апаратури i не показувати його змiни. Аналогiчнi ефекти можуть виникнути i при обробцi файлу. Мета органiзацi¨ режиму читання реальних даних поляга¹ у тотожному вiдображеннi параметрiв читання на асоцiйованому об'¹ктi суб'¹кта читання (потiк вiд асоцiйованого суб'¹- кта контролю цiлiсностi до асоцiйованого об'¹кта суб'¹кта читання) i тотожному вiдображення об'¹кта, що зчиту¹ться (вiдповiдно до параметрiв, що якi переданi суб'¹кту читання) до асоцiйованих об'¹ктiв-даних суб'¹кта контролю цiлiсностi.

Пояснимо тепер поняття якiсного контролю цiлiсностi з то- чки зору математичних властивостей функцi¨ контролю цiлiсностi.

Припустимо, що ¹ деякий об'¹кт F та деякий алгоритм H, який перетворю¹ об'¹кт F в деякий об'¹кт M, який представля¹ться словом цi¹¨ ж мови. але меншо¨ довжини. Цей алгоритм такий, що при випадковому рiвноймовiрному виборi двох об'¹ктiв F1 i F2 ç ìíî-

жини можливих вiдповiднi ¨м об'¹кти M1 = H(F1) i M2 = H(F2) з високою ймовiрнiстю ¹ рiзними. Тодi перевiрка цiлiсностi даних буду¹ться наступним чином: розгляда¹мо об'¹кт F , за вiдомим ал-

горитмом H áóäó¹ìî K = H(F ) òà ïîðiâíþ¹ìî M, заздалегiдь обчислене як M = H(F ) ç K. При спiвпаданнi вважа¹мо об'¹кт незмiнним. Алгоритм H називають, як правило геш-функцi¹ю, або рiдше контрольною сумою, а число M геш-значенням.

Якiсть контролю цiлiсностi визнача¹ться у даному випадку виконанням наступних умов:

•за вiдомим об'¹ктом M = H(F ) знаходження iншого об'¹кта G, не тотожного з F , такого, що M = H(G), ¹ завданням з трудомiсткiстю не меншою за задану Th;

•îá'¹êò M повинен бути недоступним для вимiрювань;

•довжина об'¹кта M повинна забезпечувати умовну ймовiрнiсть P (H(F1) = H(F2) (F1 не тотожний F2) не бiльше задано¨ Ph.

Смисл цих умов можна пояснити наступним чином. Нехай програма зловмисника змiнила об'¹кт F (статичне спотворення). То-

дi геш-значення M для даного об'¹кта змiниться. Якщо суб'¹кту зловмисника ¹ доступним для змiни об'¹кт M (iсну¹ вiдповiдний потiк), то вiн може за вiдомим алгоритмом H обчислити нове геш-

значення для змiненого об'¹кта замiстити ним вихiдне.

Нехай геш-значення ¹ недоступним, тодi можна спробувати так побудувати змiнений об'¹кт, що геш-значення його не змiнилося; принципова можливiсть цього ¹, оскiльки вiдображення, що зада-

¹ться алгоритмом гешування H, не бi¹ктивне (неоднозначне).

Таким чином, за умови недоступностi геш-значення для змiни та доступностi для змiни об'¹кта-джерела трудомiсткiсть порушення iзольованого програмного середовища з контролем цiлiсностi об'¹ктiв джерел (тобто можливiсть породити суб'¹кт з об'¹кта-

джерела, не тотожного вихiдному об'¹кту) спiвпада¹ з Th. Çà îäíî-

кратно¨ спроби iнiцiювати суб'¹кт iз випадково рiвноймовiрно вибраного об'¹кта-джерела ймовiрнiсть порушення iзольованого програмного середовища (успiшне породження суб'¹кта) не перевищу¹

Ph. Отже, якiсть iзольованого програмного середовища визнача-

¹ться властивостями геш-функцi¨ H, а саме: величинами Th i Ph.

Позначимо наведенi вище мiркування про метод безпечного завантаження , або схiдчастого контролю. Вiн поляга¹ у поступовому встановленнi незмiнностi компонент програмно-апаратного середовища:

• спочатку перевiря¹ться незмiннiсть програм постiйного запа-

м'ятовуючого пристрою, при позитивному результатi через перевiренi на цiлiснiсть програми зчиту¹ться завантажувальний сектор та драйвери операцiйно¨ системи (по секторах) i ¨х незмiннiсть також перевiря¹ться, крiм того перевiря¹ться цiлiснiсть об'¹кта, що визнача¹ послiдовнiсть активiзацi¨ компонент;

•через функцi¨ читання перевiрено¨ операцiйно¨ системи iнiцiю-

¹ться процес контролю породження об'¹ктiв (реалiзацiя монiтора безпеки суб'¹ктiв);

•iнiцiювання процесу контролю доступу до об'¹ктiв завершу¹

проектування гарантовано захищено¨ комп'ютерно¨ системи. Розглядаючи питання програмно-технiчно¨ реалiзацi¨ iзольо-

ваного програмного середовища, звичайно зазначають, що потужнiсть множини суб'¹ктiв у деякому сегментi комп'ютерно¨ системи (видiленому за ознакою належностi однiй ПЕОМ) з моменту увiмкнення живлення до моменту запуску процесiв користувача збiльшу¹ться. Спершу активiзуються суб'¹кти апаратнопрограмного рiвня (програми постiйного запам'ятовуючого пристрою), потiм указанi суб'¹кти породжують з об'¹ктiв-джерел даного рiвня (це, як правило, сектори зовнiшнiх носi¨в iнформацi¨) суб'¹ктiв рiвня операцiйного середовища.

Суб'¹кти рiвня операцiйного середовища, як уже вiдзначалось, також дiляться на два пiдрiвнi:

•нижнiй рiвень суб'¹кти первиннi завантажувальники операцiйно¨ системи (що працюють з iнформацi¹ю рiвня секторiв);

•верхнiй рiвень суб'¹кти-драйвери (породжуванi суб'¹ктами

первинними завантажувальниками з об'¹ктiв-секторiв), що працюють з об'¹ктами рiвня файл (послiдовнiсть секторiв). На етапi переходу вiд суб'¹ктiв вiд суб'¹ктiв-заван-

тажувальникiв до суб'¹ктiв-драйверiв вiдбува¹ться перехiд i до iншо¨ декомпозицi¨ комп'ютерно¨ системи на об'¹кти (вiд секторiв до файлiв). Указана i¹рархiя дi¹ у будь-якiй вiдомiй на сьогоднiшнiй день комп'ютернiй системi i природним чином визнача¹ архiтектуру, в рамках яко¨ форму¹ться i функцiону¹ iзольоване програмне середовище.

Наприклад, апаратна архiтектура ПЕОМ типу IBM PC зада¹ наступнi етапи активiзацi¨ рiзноманiтних рiзноманiтних суб'¹ктiв

комп'ютерно¨ системи.

При ввiмкненнi живлення ПЕОМ вiдбува¹ться тестування операцiйно¨ системи, iнiцiалiзацiя таблицi векторiв переривань та пошук розширень BIOS. При ¨х наявностi управлiння переда¹ться на них. Пiсля обробки розширень BIOS у память зчиту¹ться перший сектор дискети або вiнчестера та управлiння переда¹ться на нього (утворю¹ться код завантажника), потiм код завантажника зчиту¹ драйвери операцiйно¨ системи, потiм iнтепретуються файли конфiгурацi¨, пiдвантажу¹ться командний iнтерпретатор та викону¹ться файл автозапуску.

При реалiзацi¨ iзольованого програмного середовища на нього повинна бути покладена функцiя запускiв програм та контролю цiлiсностi.

При описуваннi методологi¨ проектування iзольованого програмного середовища згадувалася проблема контролю реальних даних. Ця проблема поляга¹ у тому, що контрольована на цiлiснiсть iнформацiя може по-рiзному представлятися на рiзних рiвнях.

Упроваджений у систему об'¹кт може вплинути на процес читання-запису даних на рiвнi файлiв (або на рiвнi секторiв) та пред'являти системi контролю деякi iншi замiсть реально iсну- ючих даних. Цей механiзм неодноразово реалiзовувався в stelsвiрусах. Проте ¹ вiрним наступне твердження.

Твердження 7 або достатня умова читання реальних даних.

Якщо суб'¹кт, який обслугову¹ процес читання даних (тобто вказаний суб'¹кт iнiцiю¹ться суб'¹ктом, що запиту¹ данi, та бере участь у потоцi), мiстив тiльки функцi¨ тотожного вiдображення даних на асоцiйованi об'¹кти-данi будь-якого суб'¹кта, що iнiцiю¹ потiк читання, i цiлiснiсть об'¹кта-джерела для цього суб'¹кта зафiксована, то при його наступнiй незмiнностi читання з використанням породженого суб'¹кта буде читанням реальних даних.

Доведення. Вiрнiсть твердження виплива¹ з визначення тотожностi суб'¹кта та з умови твердження, що гаранту¹ незмiннiсть об'¹кта-джерела.

Необхiдно i тут зробити застереження про iмовiрнiсний характер установлення незмiнностi та говорити, що читання реальних даних можливе з iмовiрнiстю, що визнача¹ться алгоритмом кон-

тролю цiлiсностi.

Метод схiдчастого контролю не суперечить твердженням 4 i 5 та передбача¹ роздiлення послiдовностi активiзацi¨ компонент Zl

на пiдпослiдовностi з однаковим рiвнем представлення iнформацi¨. Реалiзацiя методi схiдчастого контролю цiлiсностi повинна за-

довольняти умовам твердження 4.

Тепер можна описати практичну реалiзацiю сформульованих методiв.

4.3.3Реалiзацiя гарантiй виконання задано¨ полiтики безпеки

Вище було сказано про те, що суб'¹кт контролю незмiнностi об'¹ктiв, що входять у процедури активiзацi¨ комп'ютерно¨ системи та об'¹ктiв, що описують послiдовнiсть активiзацi¨ компонент, повинен бути активним уже на етапi роботи суб'¹ктiв апаратнопрограмного рiвня, але його об'¹кт-джерело не може бути перевiреним на незмiннiсть. У зв'язку з цим можна пiдкреслити надзвичайно важливий факт для будь-яких реалiзацi¨ iзольованого програмного середовища.

Àêñiîìà. Генерацiя iзольованого програмного середовища розгляда¹ться в умовах незмiнностi конфiгурацi¨ тих суб'¹ктiв ком- п'ютерно¨ системи, якi активiзуються до старту процедур контро-

лю цiлiсностi об'¹ктiв OZ та послiдовностi ZL. Незмiннiсть даних

суб'¹ктiв забезпечу¹ться зовнiшнiми по вiдношенню до власне ком- п'ютерно¨ системи методами та засобами. При аналiз або синтезi захисних механiзмiв властивостi вказаних суб'¹ктiв ¹ апрiорно заданими.

При вирiшеннi практичних питань генерацi¨ iзольованого програмного середовища можна видiлити три самостiйних напрямки.

Перший з них пов'язаний з використанням зовнiшнiх по вiдношенню до комп'ютерно¨ системи суб'¹ктiв (як правило, розташованих на зовнiшньому носi¨), цiлiснiсть яких гаранту¹ться методами зберiгання або перiодичного контролю. Зумовленiсть активiзацi¨ суб'¹ктiв, локалiзованих на зовнiшнiх носiях, забезпечу¹ться властивостями суб'¹ктiв програмно-апаратного рiвня (наприклад, можна встановити таку апаратну конфiгурацiю ПЕОМ, при якiй буде

вiдбуватися завантаження операцiйно¨ системи з гнучкого магнiтного диску).

Другий напрямок пов'язаний з локалiзацi¹ю iзольованого програмного середовища в межах обмеженого робочого мiсця (як правило, ПЕОМ) i використову¹ апаратну пiдтримку для задання напередвизначено¨ послiдовностi активiзацi¨ суб'¹ктiв. Даний напрямок, як правило, включа¹ апаратну пiдтримку автентифiкацi¨ користувачiв.

Третiй напрямок пов'язаний з реалiзацi¹ю методу довiреного завантаження операцiйного середовища з використанням уже наявних в ньому механiзмiв реалiзацi¨ та гарантування полiтики безпеки.

Необхiдно зазначити, що у рiзноманiтнi iнтервали активностi комп'ютерно¨ системи суб'¹ктами можуть управляти рiзнi кори-

стувачi, для яких множина дозволених суб'¹ктiв E ðiçíà, ó çâ'ÿç-

ку з цим можна говорити про множину Ei äëÿ i того користувача

комп'ютерно¨ системи.

Також необхiдно розумiти, що перед встановленням однозна- чно¨ вiдповiдностi множини Ei користувачевi i вiдбува¹ться про-

цедура його автентифiкацi¨.

Говорячи про перший спосiб реалiзацi¨ iзольованого програмного середовища слiд вiдзначити, що в його рамках можна розглядати конфiгурацiю iзольованого програмного середовища у двох варiантах:

•при локалiзацi¨ всiх об'¹ктiв-джерел для породження iзольо-

ваного програмного середовищ в рамках одного або декiлькох зовнiшнiх носi¨в;

•при локалiзацi¨ частини об'¹ктiв-джерел на зовнiшньому носi¨,

а частини у зовнiшнiй пам'ятi робочого мiсця.

Друга конфiгурацiя характеризу¹ться потенцiйною можливiстю порушення iзольованостi, що поляга¹ у тому, що активiзацiя суб'¹ктiв iз об'¹ктiв-джерел, що не належать зовнiшньому носiю, може здiйснюватися поза рамками iзольованого програмного середовища. Як приклад можна розглядати ситуацiю, коли програми запускаються в рамках операцiйного середовища, що завантажу¹ться з дискети. З iншо¨ сторони, запуск вказаних програм можливий i при завантаженнi операцiйно¨ системи з iншого носiя (зокре-

ма, з носi¨в робочого мiсця), i при цьому можлива активацiя i тих модулiв, якi знаходяться на дискетi.

Отже, основною задачею при використаннi зовнiшнього носiя для генерацi¨ iзольованого програмного середовища ¹ забезпечення неможливостi активiзацi¨ будь-якого суб'¹кта з об'¹кта-джерела зовнiшнього носiя поза рамок зафiксовано¨ для цього носiя послiдовностi активiзацi¨ компонент iзольованого програмного середовища.

Найбiльш раннiй спосiб проектування iзольованого програмного середовища в рамках пiдходу з використанням зовнiшнього носiя одержав назву невидимо¨ дискети. Цей спосiб поляга¹ у тому,

що всi об'¹кти, якi належать множинi OZ , i об'¹кти, що описують

ïîñëiäîâíiñòü ZL, помiщаються на зовнiшнiй носiй, з якого може

вiдбуватися завантаження операцiйно¨ системи (звичайно дискета). Незмiннiсть об'¹ктiв забезпечу¹ться фiзичним захистом носiя вiд запису.

Крiм того, використання спецiально¨ технологi¨ не дозволя¹ використовувати об'¹кти (у тому числi i забезпечити виконання програм) без завантаження операцiйно¨ системи саме з цi¹¨ дискети. Практично така дискета вигляда¹ достатньо нетривiально: буду- чи помiщеною в дисковод ПЕОМ вона як неформатована (або, в iншому варiантi, пуста). Пiсля завантаження з тако¨ пусто¨ дискети користувач вiдразу пiрна¹ в задану програму та працю¹ з нею, звертаючись у тому числi i до даних на вiнчестерi та запускаючи програми з локально незмiнних носi¨в робочого мiсця з попереднiм контролем незмiнностi вiдповiдних ¨м об'¹ктiв-джерел (виконуваних файлiв).

Запропонований спосiб дозволя¹ виключити використання виготовлено¨ дискети без завантаження з не¨. Доповнивши завантажуване з тако¨ дискети операцiйне середовище програмами перевiрки цiлiсностi можна досягнути дотримання усiх вимог iзольованостi програмно-апаратного середовища.

Як видно iз твердження 5, однi¹ю з найважливiших умов пiдтримування iзольованого програмного середовища ¹ втрата неможливостi змiн послiдовностi активiзацi¨ компонент.

У даному випадку цiлiснiсть об'¹ктiв, що мiстять послiдовнiсть активiзацi¨ компонент, гаранту¹ться фiзичною забороною запису

на дискету.

Важливою проблемою ¹ неможливiсть переривання процесу активiзацi¨ компонент. В рядi операцiйних середовищ для цього iснують штатнi можливостi, передбаченi для забезпечення захисту вiд помилок користувача, що сформував некоректну послiдовнiсть активiзацi¨ компонент операцiйно¨ системи. У зв'язку з цим повиннi бути прийнятi заходи, що гарантують пасивнiсть органiв управ-

лiння в перiод оброблення послiдовностi ZL (наприклад, апаратне блокування клавiатури з моменту активiзацi¨ модифiкованого boot до моменту закiнчення активiзацi¨ суб'¹ктiв множини SZ ).

Описаний метод пiзнiше був реалiзований у зовнiшнiх носiях типу CD-ROM, якi дозволили значно (на два порядки) збiльшити iнформацiйну ¹мнiсть носiя та завантажувати з нього розвиненi операцiйнi середовища типу OS/2. Проте однократнiсть запису сутт¹во знижу¹ гнучкiсть побудови iзольованого програмного середовища таким методом.

Незручнiсть використання завантажувально¨ дискети та ¨х швидке зношення обумовили виникнення наступного способу проектування iзольованого програмного середовища.

Можна вiдмовитися вiд завантажувально¨ дискети та розглянути ПЕОМ iз завантаженням операцiйно¨ системи з пристрою зберiгання (вiнчестера) та додатковим апаратним пристро¹м iзольованого середовища.

Розглянемо два етапи:

•етап установки iзольованого програмного середовища;

•етап експлуатацi¨ iзольованого програмного середовища. Припустимо iснування N користувачiв, кожний i-òèé ç ÿêèõ

характеризу¹ться деякою персональною iнформацi¹ю Ki, ÿêà ¹ íå-

вiдомою iншим користувачам та зберiга¹ться на деякому матерiальному носi¨ (наприклад, пристро¨ сенсорно¨ пам'ятi типу touch memory). iсну¹ також адмiнiстратор системи з iзольованим про-

грамним середовищем, якiй зна¹ усi Ki та одноосiбно проводить

етап установки. Користувачi (власники Ki) беруть участь тiльки

на етапi експлуатацi¨.

Процес установки iзольованого програмного середовища склада¹ться з наступних дiй.

1. В ПЕОМ установлю¹ться апаратний модуль, що включа¹

пристрiй та програми постiйного запам'ятовуючого пристрою даного пристрою (суб'¹кти програмно-апаратного рiвня), що реалiзують:

•операцi¨ сервiсу носiя, що автентифiку¹ться, користувача Ki (як мiнiмум його читання);

•автентифiкацiю користувача з номером i за введеним ним Ki;

•читання масиву даних, що мiстить множину доступних для

користувача i об'¹ктiв-джерел (виконуваних модулiв) Fi1, Fi2,...,Fim, що складають об'¹кт OZ ;

•обчислення iнформацi¨ Mi1, Mi2,...,Mim, що фiксу¹ цiлiснiсть об'¹ктiв-джерел Fi1, Fi2,...,Fim кожного об'¹кта-джерела (iн- формацiя Mij повинна задовольняти вимогам геш-значень i, можливо, залежати вiд Ki), Mij = H(Ki, Fij);

•блокування пристро¨в управлiння та попередження завантаження операцiйного середовища iз зовнiшнього носiя.

2.Адмiнiстратор визнача¹ для користувачiв i набiр потенцiйно

можливих для активiзацi¨ суб'¹ктiв Ei, Ei = {Pi1, ..., Pim}, i =

1, .., N.

Create(Pik, Fij) → Pij,

mi число дозволених до запуску задач для i-го користувача. 3. Адмiнiстратор форму¹ (i заносить на носiй) або зчиту¹ з носiя äëÿ i-ãî користувача його Ki та обчислю¹ значення для наступного

контролю цiлiсностi Mijr = H(Ki, Fjr), äå H функцiя контролю цiлiсностi (геш-функцiя).

4.Адмiнiстратор викону¹ дi¨ 2 i 3 для всiх H користувачiв.

5.Адмiнiстратор встановлю¹ в комп'ютерну систему монiтор безпеки суб'¹ктiв з об'¹ктом-джерелом F iïñ òà ôiêñó¹ éîãî öiëi-

снiсть. Установка модуля вiдбува¹ться з урахуванням умов твердження 5.

6. Адмiнiстратор фiксу¹ цiлiснiсть об'¹кта, що мiстить ZL.

Процес експлуатацi¨ поляга¹ у виконаннi наступних дiй.

6.1. Включення живлення та активiзацiя апаратного модуля: а) Iдентифiкацiя користувача i ïî Ki.

Якщо iдентифiкацiя проходить, то викону¹ться пункт б), а якщо нi, то ПЕОМ блоку¹ться.

б) Перевiрка цiлiсностi усiх встановлених в ПЕОМ постiйних запам'ятовуючих пристро¨в.

Якщо результат позитивний, то викону¹ться пункт в), а якщо нi, то ПЕОМ блоку¹ться.

в) Читання секторами файлiв операцiйно¨ системи та перевiрка ¨х цiлiсностi.

г) Читання як файла F iпс (за допомогою функцiй операцiйно¨ системи) та перевiрка його цiлiсностi. Як варiант може бути читання F iпс секторами.

д) Активiзацiя процесу контролю P iïñ. Create(Sz, F iïñ) → P iпс. Активiзацiя монiтора безпеки об'¹ктiв.

е) Запуск вибрано¨ задачi i-го користувача (може не виконува-

òèñÿ).

6.2. Робота в iзольованому програмному середовищi. Запуск кожного процесу PS супроводжу¹ться перевiрками:

а) Чи належить Fs до множини дозволених для i (Ei), якщо так, то викону¹ться пункт б), якщо нi, то запуск iгнору¹ться.

б) Чи спiвпадають G = H(Ki, FS) ç M = H(Ki, FS), обчислен-

ною адмiнiстратором.

в) Якщо так, то то задача запуска¹ться, у протилежному випадку запуск iгнору¹ться.

Легко бачити, що умова iзольованостi середовища виконана. Крiм того, у даному випадку реалiзованих механiзм схiдчасто-

го контролю, що забезпечу¹ читання реальних даних.

При доповненнi в iзольованому програмному середовищi реалiзацi¨ монiтору безпеки об'¹ктiв та виконаннi умов, пред'явлених вище, до суб'¹ктiв, що входять до iзольованого програмного середовища, сформоване програмне середовище буде гарантовано захищеним в рамках полiтики безпеки, реалiзовано¨ в монiторi безпеки об'¹ктiв.

Використовуючи твердження 4 про однаковiсть станiв комп'ю- терно¨ системи пiсля активiзацi¨ перевiрених на незмiннiсть суб'¹- ктiв у незмiннiй послiдовностi, можна описати метод довiреного завантаження компонент операцiйного середовища (коротко ìå-

тод довiреного завантаження ).

Нехай визначений порядок завантаження компонентiв операцiйно¨ системи (пiд завантаженням компонент операцiйно¨ системи розумiють активiзацiю рiзноманiтних суб'¹ктiв операцiйно¨ систе-

ми iз вiдповiдних об'¹ктiв-джерел рiзного рiвня i¹рархi¨). Процедуру завантаження операцiйно¨ системи називають довiреною, якщо:

•встановлена незмiннiсть компонент операцiйно¨ системи опера-

цiйно¨ системи (об'¹ктiв), що беруть участь у завантаженнi (iншими словами

•об'¹ктiв, що належать множинi OZ , причому незмiннiсть вста- новлена до породження першого суб'¹кта з ZL;

•встановлена незмiннiсть об'¹ктiв, що визначають послiдовнiсть

активiзацi¨ компонент операцiйно¨ системи (з урахуванням декiлькох рiвнiв i¹рархi¨), незмiннiсть забезпечена протягом заданого iнтервалу часу;

•стан вказаних об'¹ктiв не може бути змiнений нiким, крiм напередвизначеного користувача (користувачiв) комп'ютерно¨ системи (ця умова вiдповiда¹ незмiнностi послiдовностi ZL.

Легко бачити, що процедура довiреного завантаження забезпе- чу¹ однаковий стан комп'ютерно¨ системи пiсля виконання завантаження (вiдповiдно до твердження 4).

Основна технiчна проблема при реалiзацi¨ довiреного завантаження поляга¹ у доступi до об'¹ктiв вищого рiвня i¹рархi¨ операцiйно¨ системи (файлiв) до завантаження ядра дано¨ операцiйно¨ системи (завантажувану операцiйну систему будемо називати користувальницькою). Проте при можливостi генерацi¨ iзольованого програмного середовища для будь-яко¨ iншо¨ системи (дальше будемо називати ¨¨ базовою) можна запропонувати iтеративну реалiзацiю довiреного завантаження з використанням ресурсiв указано¨ операцiйно¨ системи.

Розглянемо реалiзацiю довiреного завантаження операцiйно¨ системи на основi генерацi¨ iзольованого програмного середовища для одного з операцiйних середовищ обчислювально¨ системи.

Припустимо, що iсну¹ базова операцiйна системи, для яко¨ можлива повноцiнна генерацiя iзольованого програмного середовища. Нехай у обчислювальнiй системi iснують ще операцiйнi систе-

ìè OS1, OS2,...,OSn. Ставиться задача довiреного запуску опера-

цiйного середовища OSj. Нехай у базовiй iнформацiйнiй системi ¹ деяке умовно назване шлюзове програмне забезпечення мiж ба-

зовою операцiйною системою та OSj. Функцi¨ шлюзового програм-

ного забезпечення полягають у забезпеченнi доступу до файлово¨ системи OSj (тобто до об'¹ктiв рiвня R).

Нехай користувач ма¹ фiзичний доступ до комплекта технiчних засобiв (робочого мiсяця) мережi (ЕОМ) Tm, на якому встановлена операцiйна система OSj. При використаннi комплекту Tm користувачем i.

1. Вiдбува¹ться автентифiкацiя користувача i (за його iндивiдуальною iнформацi¹ю).

2.Перевiряються права користувача з використання апаратно¨ компоненти Tm.

3.Контролю¹ться цiлiснiсть (на основi iнформацi¨ користувача

Ki або без не¨) всiх об'¹ктiв базово¨ операцiйно¨ системи, розташованих на деякому носi¹вi, локально або вiддалено (через технiчнi засоби локально¨ обчислювально¨ мережi) зв'язаному з Tm.

4.Завантажу¹ться базова базова операцiйна система та контролю¹ться цiлiснiсть шлюзового програмного забезпечення.

5.Завантажу¹ться шлюзове програмне забезпечення (при цьому ста¹ доступною як мiнiмум в режимi читання файлова стру-

ктура OSj, що розташована локально на Tm);

6.Контролю¹ться цiлiснiсть об'¹ктiв рiвнiв, менших Rj (Rj максимальний рiвень представлення об'¹ктiв в OSj (äèâ. âèùå).

7.Контролю¹ться цiлiснiсть об'¹ктiв рiвня Rj (ôàéëiâ) OSJ.

8.Контролю¹ться цiлiснiсть об'¹кта, що зада¹ послiдовнiсть завантаження компонент.

9.Здiйсню¹ться примусове завантаження (iнiцiю¹ться напере-

дзаданий в силу цiлiсностi об'¹ктiв OZ i послiдовностi Zi порядок завантаження компонент операцiйно¨ системи) перевiрено¨ на цiлiснiсть OSj

Легко показати, що при додаткових вимогах до довiрено завантажено¨ операцiйно¨ системи (а саме гарантованому включеннi механiзму контролю запуску задач i якiсному (у смислi перехоплення усiх запитiв на запуск ядром операцiйно¨ системи) контролi запуску задач, а також при коректному управлiннi списком дозволених задач для завантажено¨ за допомогою описаного алгоритму операцiйно¨ системи) породжу¹ться iзольоване програмне середовище.

Твердження 8 або умови генерацi¨ iзольованого програмного се-

редовища при реалiзацi¨ методу довiреного завантаження.

Нехай ядро операцiйно¨ системи мiстить монiтор безпеки об'¹- ктiв та монiтор безпеки суб'¹ктiв, iнiцiйованi в операцiйнiй системi суб'¹кти попарно коректнi, ¨х об'¹кти-джерела належать множинi перевiрюваних на незмiннiсть в ходi довiреного завантаження, монiтор безпеки об'¹ктiв забороня¹ змiну будь-якого об'¹кта-джерела i виконана процедура довiреного завантаження операцiйно¨ системи. Тодi пiсля iнiцiювання ядра операцiйно¨ системи генеру¹ться iзольоване програмне середовище.

Доведення. Процедура довiреного завантаження за побудовою забезпечу¹ незмiннiсть OZ i ZL, за умовою твердження про породження суб'¹ктiв ¹ дозволеними тiльки об'¹кти-джерела, що OZ

належать OZ , незмiннiсть об'¹ктiв-джерел за умовою гаранту¹ться

властивостями монiтора безпеки об'¹ктiв. Отже, виконаннi умови твердження 5 та генеру¹ться iзольоване програмне середовище. Твердження доведене.

Ðîçäië 5

Стандартизованi моделi та методи оцiнки ефективностi захисту

5.1Модель, що покладена в основу мiжнародного стандарту ISO 7498-2

5.1.1I¹рархiчна декомпозицiя в моделi OSI/ISO

Одним з розповсюджених прикладiв i¹рархiчно¨ структури мов для опису складних систем ¹ розроблена Мiжнародною органiзацi¹ю зi стандартизацi¨ (ISO) Еталонна модель вза¹модi¨ вiдкритих систем [Open Systems Interconnection (OSI) model]. Вона вiдiгра¹ важливу роль як методологiчна, концептуальна i термiнологiчна основа побудови обчислювальних мереж. Описана в

стандартi ISO/IEC 7498-2 (äèâ. ðèñ. 5.1).

Модель склада¹ться iз семи рiвнiв фiзичного, канального, мережного, сеансового, представницького та прикладного, для кожного з яких створенi сво¨ стандарти i загальнi моделi.

Верхнi рiвнi вирiшують завдання подання даних користувачевi у такiй формi, яку вiн може розпiзнати та використати. Нижнi рiвнi служать для органiзацi¨ передавання даних.

I¹рархiя поляга¹ у наступному. Усю iнформацiю у процесi передавання повiдомлення вiд одного користувача (процесу) до iншого можна розбити на рiвнi; кожний рiвень ¹ виразом деяко¨ мови, яка опису¹ iнформацiю свого рiвня. У термiнах мови даного рiвня виража¹ться перетворення iнформацi¨ i послуги , якi на цьому рiвнi надаються наступному рiвню. При цьому, сама мова опира¹ться на основнi елементи, якi ¹ послугами мови бiльш низького рiвня. У моделi вза¹модi¨ вiдкритих систем мова кожного рiвня разом з порядком його використання назива¹ться протоколом цього рiвня.

Розглянемо призначення кожного рiвня, та представлення мо-

Ðèñ. 5.1. Модель вза¹модi¨ вiдкритих систем

ви кожного рiвня.

Прикладний рiвень [application level] ма¹ вiдношення до семантики iнформацi¨, якою обмiнюються, (тобто до ¨¨ смислу). Мова прикладного рiвня забезпечу¹ вза¹морозумiння двох прикладних процесiв у рiзних точках, що сприя¹ здiйсненню бажаного оброблення iнформацi¨. Мова прикладного рiвня опису¹ два види ситуацiй:

•загальнi елементи для всiх прикладних процесiв, що вза¹модiють на прикладному рiвнi;

•специфiчнi, що не пiдлягають стандартизацi¨, елементи застосувань.

Мова прикладного рiвня склада¹ться та постiйно розширю¹ться за рахунок функцiональних пiдмов. Наприклад, розробленi наступнi протоколи (мови прикладного рiвня):

•вiртуальний термiнал (надання доступу до термiналу процесу користувача у вiддаленiй системi);

•файл (дистанцiйний доступ, управлiння та передавання iнформацi¨, накопичено¨ у формi файлу);

•протоколи передавання завдань та манiпуляцi¨ (розподiлена обробка iнформацi¨);

•менеджерськi протоколи.

Одним з важливих протоколiв прикладного рiвня ¹ електронна пошта (протокол X.400), тобто транспортування повiдомлень мiж незалежними системами з рiзноманiтними технологiями передавання та доставки повiдомлень.

Представницький рiвень [presentation level] вирiшу¹ тi проблеми вза¹модi¨ прикладних процесiв, якi зв'язанi з рiзноманiттям представлення цих процесiв. Представницький рiвень нада¹ послуги для двох користувачiв, якi бажають зв'язатися на прикладному рiвнi, забезпечуючи обмiн iнформацi¹ю вiдносно синтаксису даних, що передаються мiж ними. Це можна зробити або у формi iмен, якщо обом системам, що зв'язуються, вiдомий синтаксис, яким будуть користуватися, або у формi опису синтаксису, який буде використовуватися, якщо вiн ¹ невiдомим. Якщо синтаксис iнформацi¨, що переда¹ться, вiдрiзня¹ться вiд синтаксису, яка використову¹ться приймальною системою, то представницький рiвень повинен забезпечити вiдповiдне перетворення.

Крiм того, представницький рiвень забезпечу¹ вiдкривання та закривання зв'язку, управлiння станом представницького рiвня та контролем помилок.

Сеансовий рiвень [session level] забезпечу¹ управлiння дiалогом мiж обслуговуваними процесами на представницькому рiвнi. Сеансове з'¹днання спочатку повинно бути встановлене, а параметри з'¹днання обговоренi шляхом обмiну iнформацi¹ю управлiння. Сеансiв рiвень нада¹ послугу синхронiзацi¨ для подолання будьяких виявлених помилок.

Це здiйсню¹ться наступним чином: мiтки синхронiзацi¨ вставляються у потiк даних користувачами послуги сеансу. Якщо вияв-

лена помилка, сеансове з'¹днання повинно повернутися у встановлену точку дiалогового потоку iнформацi¨, скинути частину переданих даних а потiм вiдновити передачу, починаючи з цi¹¨ точки.

Транспортний рiвень [transport level] представля¹ сеансовому рiвневi послугу у виглядi надiйного та прозорого механiзму передавання даних (незалежно вiд виду реально¨ мережi) мiж вершинами мережi.

Мережний рiвень [network level] нада¹ транспортному рiвневi послуги зв'язку. Мережний рiвень визнача¹ маршрут у мережi. Органiзову¹ мережний обмiн (протокол IP). Управля¹ потоками в мережi.

Канальний рiвень [link level] нада¹ мережному рiвневi послуги каналу. Ця послуга поляга¹ у безпомилковiй послiдовного передавання блокiв даних каналом у мережi. На цьому рiвнi реалiзу¹ться синхронiзацiя, порядок блокiв, виявлення та виправлення помилок, лiнiйне шифрування.

Фiзичний рiвень [physical level] забезпечу¹ те, що символи, якi поступають у фiзичне середовище передавання на одному кiнцi, досягали другого кiнця.

Для реалiзацi¨ функцi¨ обмiну iнформацi¹ю на кожному рiвнi до вхiдного блоку даних дода¹ться iнформацiя у видi вираження мови вiдповiдного рiвня (як правило у виглядi додаткового заголовка).

Рiвнi функцiонально вза¹модiють, по-перше, як однаковi рiвнi у рiзних абонентiв, по-друге, як сумiжнi рiвнi в однiй i¹рархi¨. Зв'я- зок будь-яких однакових рiвнiв у рiзних абонентiв при передачi, що використову¹ з'¹днання, склада¹ться з трьох фаз:

•встановлення з'¹днання;

•передавання даних;

•роз'¹днання.

Óпершiй фазi вiдбуваються домовленостi про набiр параметрiв передачi. У другiй фазi виявлення та виправлення помилок, пiдтримка з'¹днання.

На кожному рiвнi сво¨ способи виявлення та виправлення помилок:

•на канальному рiвнi виправлення бiтiв;

•на мережному роз'¹днання та втрата пакетiв; вiдповiдно виправлення цих помилок;

•на сеансовому, транспортному виправлення адресацi¨.

Якщо важливi iнформацiйнi елементи кожного рiвня назвати об'¹ктами, то зв'язок (N-1)-го, N-го i (N+1)-го рiвнiв вигляда¹ наступним чином (див. рис. 5.2) кожний рiвень мiстить набiр об'¹- ктiв, якi вза¹модiють мiж собою у рiзних системах на одному рiвнi. На рiзних рiвнях об'¹кти вза¹модiють через ключi доступу послуг.

Ðèñ. 5.2. Âçà¹ìîäiÿ ðiâíiâ i¹ðàðõi¨

У моделi вза¹модi¨ вiдкритих систем стандартизованi види вза¹модi¨ постачальника послуги на рiвнi N та споживача на рiвнi (N+1). Цi види називаються примiтивами послуг. х чотири (див. рис. 5.3):

Ðèñ. 5.3. Âèäè âçà¹ìîäi¨

•запит;

•ознака;

•âiäïîâiäü;

•пiдтвердження.

Запит пода¹ться користувачем послуги на (N+1) рiвнi системи A для того, щоб звернутися до послуги протоколу постачальника послуги на N-му рiвнi. Це призводить до посилки повiдомлення N-

го рiвня в систему B. У системi B запит на рiвнi N виклика¹ появу примiтива ознака , що випуска¹ться постачальником послуги на рiвнi N у B на (N+1)-ий рiвень.

Примiтив вiдповiдь випуска¹ться користувачем послуги на рiвнi (N+1) у B у вiдповiдь на ознаку, що з'явилася у точцi доступу до послуги мiж рiвнями N i (N+1) системи B. Примiтиввiдповiдь ¹ директивою протоколу рiвня N завершити процедуру звернення примiтива ознака . Протокол на рiвнi N у системi B генеру¹ повiдомлення, яке переда¹ться у мережi та повторю¹ться на рiвнi N системи A. Це виклика¹ посилання примiтива пiдтвердження , який випуска¹ться постачальником послуги в системi A на рiвнi N у точцi доступу до послуги мiж рiвнями N i (N+1). Ця процедура, розпочата запитом у точцi доступу до послуги мiж рiвнями N i (N+1) в системi A завершу¹ться.

5.1.2 Загрози в архiтектурi вiдкритих мереж

В архiтектурi вiдкритих мереж використову¹ться поняття категорiя загрози .

Категорiя загрози пов'язана iз загрозою безпецi iнформацi¨ (даних) в телекомунiкацiйних мережах. Для МВВС видiляють п'ять категорiй загроз:

•розкриття змiсту повiдомлень, що передаються;

•аналiз трафiка, що дозволя¹ визначити належнiсть вiдправника i одержувача даних до однi¹¨ з груп користувачiв мережi;

•змiна потоку повiдомлень, що може привести до порушення

режиму роботи будь-якого об'¹кта, що керу¹ться з вiддалено¨ ЕОМ;

•неправомiрна вiдмова в наданнi послуг;

•несанкцiоноване встановлення з'¹днання.

Згiдно до визначення термiна безпека iнформацi¨ першу i другу загрозу можна вiднести до витоку iнформацi¨, третю i п'яту до ¨¨ модифiкацi¨, а четверту загрозу до порушення процесу обмiну iнформацi¹ю, тобто до ¨¨ втрати.

На фiзичному та канальному рiвнях iмовiрнi наступнi загрози:

•несанкцiоноване пiдключення;

•помилкова комутацiя; прослуховування;