68

Роздiл 4

Рис. 4.7. Приклад дiаграми дерева загроз

Бiльш детальний огляд наведений в:

1)Swiderski, Snyder, “Threat Modeling”, Microsoft Press, 2004.

2)“Improving Web Application Security”, (Chapter 3), Microsoft Press, 2004.

3)Howard, LeBlanc, “Writing Secure Code” (Chapter 4), Microsoft Press, 2004.

4.2.8 Методика OCTAVE

Загальна структура методики наведена на рис. 4.8 Склад основних етапiв:

Етап 1 Побудова профiлю загроз, що враховує цiннiсть iнформацiї. Визначення (рис. 4.9):

–критичних ресурсiв;

–вимог щодо забезпечення безпеки критичних ресурсiв;

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

69

Рис. 4.8. Загальна структура методики OCTAVE

–загроз критичним ресурсам;

–наявних мiр та засобiв захисту;

–вразливостей системи.

Етап 2 Формування структури вразливостей. Визначення (рис. 4.10):

–технологiй оброблення (бiзнес процесiв);

–наявних вразливостей для технологiй оброблення.

Етап 3 Розробка полiтики (стратегiї) безпеки та плану її реалiзацiї. Шляхом (рис. 4.10):

–оцiнки ризику цiнним ресурсам;

–визначення допустимого ризику;

–формування полiтики (стратегiї) безпеки;

–формування плану зменшення ризику.

4.2.9 Методика Agile Security Modeling (ASM)

Основнi риси:

1) за аналогiєю до полегшених процесiв розроблення ПЗ;

70

Роздiл 4

Рис. 4.9. Процеси етапу 1. Побудова профiлю загроз, що враховує цiннiсть iнформацiї.

2)врахування близької перспективи;

3)орiєнтацiя на змiннiсть системи;

4)вiдсутнiсть дублювання мiр захисту;

5)iнкрементальнiсть;

6)орiєнтацiя моделi на розроблення програмного коду.

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

71

Рис. 4.10. Етап 2. Формування структури вразливостей.

4.2.10Приклад створення анкети для оцiнки складу загроз та аналiзу ризикiв

Наведемо приклад анкети для проведення попереднiх робiт з формування моделi загроз та аналiзу ризикiв [48] (рис. 4.12, 4.13).

4.2.11Програмнi засоби аналiзу рiвня захищеностi (ризику) обчислювальних систем

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

COBRA Програмний засiб для проведення базового аналiзу ризикiв. COBRA суттєво дозволяє полегшити процес аудиту iнформацiйної безпеки на вiдповiднiсть системи вимогам стандарту BS 7799 (ISO 17799). Є декiлька баз знань: загальнi вимоги BS 7799 (ISO 17799) та спецiалiзованi базы, орiєнтованi на рiзнi галузi використання. Розробник C and A Systems Security Ltd, http://www.securityauditor.net;

CRAMM (Logica, Великобритания); MARION (CLUSIF, Франция);

RiskPAC ПЗ анализу ризикiв базового рiвня. Галузь використан-

72

Роздiл 4

Рис. 4.11. Етап 3. Розробка полiтики (стратегiї) безпеки та плану її реалiзацiї.

ня перевiрка вiдповiдностi вимогам базового уровня захищеностi органiзацiї CSCI. Є можливiсть налагодження на рiзнi галузi використання шляхом додавання путем (виключення) додаткових питань для проведення опросу. Є можливiсть оцiнки середньорiчних збиткiв iнформацiйним активам, що очiкуються в наслiдок проведення атак. Розробник CSCI, http://www.csciweb.com; RiskWatch ПЗ спрощеного детального анализу ризикiв. Розро-

бник Riskwatch (США), http://www.riskwatch.com.
BSS Baseline	Security	Survey.	(ftp://
ftp.rmcs.CRANFIELD.AC.UK /pub/department /ess/bss).
Automated Information Systems Security Policy Manual,			NIST,
http://fedworld.gov;
Кондор (Digital Security, dsec.ru).

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

73

Рис. 4.12. Анкета для оцiнки складу загроз та аналiзу ризикiв. Частина 1

4.3Пiдходи до визначення витрат на розроблення систем захисту

4.3.1Пiдхiд на основi оцiнки ризику

Є одним з найбiльш характерних, вперше запропонований компанiєю IBM (викладений та проаналiзований в [49, п. 4.4]). Основна iдея: визначення та порiвняння значень вартостi Czax створення системи захисту, збиткiв Czbt вiд реалiзацiї загроз (в тому числi з урахуванням цiнностi iнформацiї) в залежностi вiд складностi системи захисту. Оптимальна складнiсть системи захисту визначається виходячи з загальних втрат Cvtr системи:

Cvtr = Czax + Czbt

(4.1)

Спiввiдношення цих характеристик вiдображено на рис. 4.14. Варiанти рiшення, в залежностi вiд постановки завдання на розроблення системи захисту (див. п.п. 3.4): 1) min(Cvtr); 2) min(Czbt).

Основнi проблеми:

74

Роздiл 4

Рис. 4.13. Анкета для оцiнки складу загроз та аналiзу ризикiв. Частина 2

–адекватнiсть опису;

–оцiнки вартостi збиткiв, системи захисту;

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

75

Рис. 4.14. Пiдхiд на основi оцiнки ризику

–отримання функцiональних залежностей;

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

та iнтенсивностей появи загроз, вартостi втрат, та iн.) для загальної оцiнки захищеностi наведений в [8, п. 3.4.2] (фактично узагальнений та розвинутий матерiал [49,50]).

4.3.2 Пiдхiд на основi оцiнки захищеностi системи

Як свiдчать результати багатьох дослiджень, залежностi вартостi систем захисту, ефективностi систем захисту, загальної продуктивностi систем, що захищаються, вiд складностi систем захисту в загальному випадку мають експоненцiйний вигляд. Приклад визначення цих залежностей та взаємозв’язку мiж ними для оцiнки захищеностi систем в рiзних випадках постановки завдання захисту наведений на рис. 4.15 [8, п. 3.4.4-3.4.5].

76

Роздiл 4

Рис. 4.15. Пiдхiд на основi оцiнки захищеностi системи

4.3.3Рекомендацiї щодо формування архiтектури системи захисту та визначення витрат на її розроблення

Висновки з аналiзу пiдходiв оцiнки захищеностi системи [8, п. 3.4.3-3.4.5], [51]:

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

обрання варiанту, який забезпечує максимальний рiвень захищеностi за допустимих витрат (вартiсть системи захисту, обсяг накладних витрат на її функцiонування, варiант 2 п.п. 3.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тик безпеки

77

системи захисту);

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

4.4 Канали витоку iнформацiї в КСМ

взяти з курсу 2004 року.

4.5Приклад методики попереднього аналiзу ефективностi та визначення загальної органiзацiї КЗЗ

Як приклад, наведемо загальну модель та можливий варiант її використання для опису КЗЗ IТС:

загальна структура моделi опису КЗЗ IТС (див. рис 4.16);

загальна схема технологiчних процесiв оброблення iнформацiї (див. рис 4.17);

загальна структура IТС (див. рис 4.18);

приклад моделювання опису КЗЗ IТС (див. рис 4.19).

Питання та практичнi завдання

1.Аналiз iнформацiйних потокiв та вiдображення їх на вiдповiдних схемах.

2.Визначення моделей загроз.

3.Визначення моделей порушника.

4.Використання методик аналiзу ризикiв.

78

Роздiл 4

Рис. 4.16. Загальна структура моделi опису КЗЗ IТС

Рис. 4.17. Загальна схема технологiчних процесiв оброблення iнформацiї

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

79

Рис. 4.18. загальна структура IТС

80

Роздiл 4

Рис. 4.19. Приклад моделювання опису КЗЗ IТС

Роздiл 5

ПIДХОДИ ДО ФОРМУВАННЯ ПОЛIТИКИ БЕЗПЕКИ КОМП’ЮТЕРНИХ СИСТЕМ ТА МЕРЕЖ

5.1Формування полiтики безпеки АС

5.1.1Роль полiтики безпеки в формуваннi системи захисту

Визначення поняття безпечного стану КСМ та вимог щодо його забезпечення. Поняття нелегiтимного доступу та прихованих каналiв витоку iнформацiї, причини виникнення.

Пiдходи до опису ПБ. Перевiрка правильностi формування ПБ. Комплекснiсть формування ПБ.

Формування полiтики безпеки досить докладно розглянуто в наступних виданнях [52,4,43].

5.1.2 Основнi складовi полiтики безпеки

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

НД ТЗI: 1.1-002-99 “Загальнi положення” [19], 1.4-001-00 “Методичнi вказiвки щодо розроблення ТЗ на КСЗI” [20], 2.5-004-99 “Критерiї оцiнки” [22], 2.5-005-99 “Класифiкацiя АС та стандартнi ФП” [23], 3.7-001-99 “Положення про службу захисту” [21].

Мiжнароднi стандарти: ISO/IEC 13335 “Management of information and communications technology security”, ISO/IEC “17799 Code of Practice for information security management”, ISO/IEC 15408 “Common criteria for Information Technology Security Evaluation”.

81

82

Роздiл 5

Нормативнi документи iнших держав: NIST 800-12 “An Introduction to Computer Security: The NIST Handbook”, NIST 800-14 “Generally Accepted Principles and Practices for Securing Information Technology Systems”, NIST 800-18 “Guide for Developing Security Plans for Information Technology Systems”;

Основнi роздiли, якi можуть входити до складу полiтики безпеки (ПБ) обчислювальної (автоматизованої) системи:

1.Загальнi положення

1.1.Призначення формування документу

1.2.Цiлi забезпечення безпеки iнформацiї в системi

1.3.Нормативно-правова база формування системи захисту

1.4.Термiни та визначення, що використовуються

2.Область дiї

2.1.Система, що розглядається (загальне визначення її складу та меж).

2.2.Iнформацiя, яка захищається (її загальна характеристи-

ка).

2.3.Структури компанiї, на якi поширюється дiя документу.

3.Базовi положення полiтики безпеки

3.1.Визначення загальних принципiв забезпечення безпеки

всистемi.

3.2.Опис правил зберiгання та оброблення цiнної iнформацiї,

втому числi:

1)порядок надання та позбавлення прав роботи користувачiв в системi;

2)порядок надання та позбавлення доступу до ресурсiв;

3)порядок управлiння доступом до ресурсiв;

4)порядок збереження та розподiлу iнформацiї;

5)порядок обробки цiнної iнформацiї (документiв);

6)яким чином оцiнюється стан захищеностi АС;

7)правила взаємодiї з iншими системами;

8)правила створення та облiку твердих копiй документiв;

9)розподiл повноважень щодо адмiнiстрування системи (адмiнiстративнi ролi);

10)органiзацiя супроводження системи.

Стандартизованi моделi та методи оцiнки ефективностi захисту

83

4. Вiдповiдальнiсть за виконання положень докумен-

ту

4.1.Правова база (загальнодержавнi документи та внутрiшнi документи компанiї).

4.2.Санкцiї за порушення вимог даної полiтики безпеки.

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

5.Порядок реагування на порушення полiтики безпе-

ки

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

5.1.3Система документiв, що забезпечують реалiзацiю полiтики безпеки

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

рiзного рангу полiтик;

планiв;

iнструкцiй та правил;

кодексiв;

та iн.

Приклад формування системи документiв для систем в США, розроблений NIST наведений на рис. 5.2):

План захисту (security plan) документ, що визначає порядок побудови та експлуатацiї СЗ. Основними питаннями, що розглядаються в ньому є (в тому числi з урахуванням iснуючих документiв):

1)завдання захисту iнформацiї в АС;

2)класифiкацiя критичної iнформацiї;

3)опис компонентiв АС та технологiй оброблення iнформацiї;

4)опис загроз;

84

Роздiл 5

Рис. 5.1. Структура нормативних документiв з забезпечення захисту

5)порядок формування та коригування ПБ;

6)порядок та шляхи створення КСЗI;

7)порядок введення в дiю КСЗI;

8)порядок та основнi заходи з пiдтримки КСЗI;

9)вiдповiдальнiсть персоналу.

5.1.4 Види полiтик безпеки

Основними видами полiтик безпеки, вiдповiдно до яких формуються правила управлiння доступом до ресурсiв системи є [9,1]:

дискрецiйна;

ролева;

мандатна.

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

Стандартизованi моделi та методи оцiнки ефективностi захисту

85

Рис. 5.2. Структура нормативних документiв з забезпечення захисту NIST

5.1.5 Приклади визначення полiтики безпеки

Приклади:

неформалiзовано (один з вiдомих прикладiв полiтика безпеки Internet сайту [53]);

частково формалiзовано [9,1];

формалiзовано (Multics, ADEPT, Hydra) [9].

5.1.6 Пiдходи до формування полiтики безпеки

Визначення зон (доменiв безпеки). Наприклад за рiвнями ВВС (модель безпеки стандарту ISO 7498-2) чи органiзацiєю програмного та апаратного забезпечення системи (див. рис. 5.3).

Визначення станiв системи (безпечних чи небезпечних) та можливих переходiв мiж ними. Приклад визначення станiв, для фор-

86

Роздiл 5

Рис. 5.3. Приклад визначення доменiв безпеки

мування полiтики безпеки, наведений на рис. 5.4.

5.1.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 захисту

87

Рис. 5.4. Приклад визначення станiв функцiонування системи

ється чи створена (див. рис. 5.5).

Досягнення необхiдного (встановленого) рiвня гарантiй забезпечується комплексом заходiв. Система цих заходiв вiдповiдно до НД ТЗI 2.5-004-99 [23] та ISO 15408 [31] наведенi на рис. 5.6.

5.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 КЗЗ.

Див. [1, п. 1.5], [52].

88

Роздiл 5

Рис. 5.5. Порiвняльний аналiз вимог щодо гарантiй правильностi реалiзацiї ПБ

5.2.1Урахування взаємозв’язку понять живучостi, захищеностi, надiйностi

Взаємозв’язок мiж цiлями побудови систем захисту може бути вiдображений наступним чином (рис. 5.7) [10].

5.2.2 Основнi рiвнi захисту ресурсiв АС

Основнi рiвнями захисту (рiвнями розташування механiзмiв захисту) для сучасних обчислювальних систем та мереж є [3, п.п. 3.1], [54]:

1.мережної взаємодiї (сеансовий, мережний, канальний рiвнi);

2.системний (операцiйна система);

3.функцiональний (СУБД, прикладне програмне забезпечення, система електронної пошти та iн.)

Стандартизованi моделi та методи оцiнки ефективностi захисту

89

Рис. 5.6. Система вимог щодо забезпечення гарантiй правильностi реалiзацiї ПБ

Рiвнi та вiдповiднi об’єкти захисту наведенi в табл. 5.1.

5.2.3 Розроблення правил iнформацiйної безпеки

Див. [52].

5.3Засоби формування та перевiрки правильностi виконання правил полiтик безпеки

Див. [4].

5.4Типовi пiдходи та методи формування захищених розподiлених IТС

Див. [55,56,57,41,3].

90

Роздiл 5

Рис. 5.7. Iєрархiя вимог до систем захисту

Питання та практичнi завдання

1.Аналiз iнформацiйних потокiв та вiдображення їх на вiдповiдних схемах.

2.Визначення моделей загроз.

3.Визначення моделей порушника.

4.Використання методик аналiзу ризикiв.

Стандартизованi моделi та методи оцiнки ефективностi захисту

91

Табл. 5.1 Основн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ЙНИХ СИСТЕМ

6.1Сервiси безпеки як основа пiдтримки полiтики безпеки

6.1.1Сервiси безпеки

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

Окремо зупинимося на сучасних сервiсах безпеки [88]. Якими би потужними i стiйкими вони не були, самi по собi вони не можуть гарантувати надiйнiсть програмно-технiчного рiвня захисту. Тiльки єдина архiтектура безпеки здатна зробити ефективним об’- єднання цих сервiсiв, забезпечити керованiсть IС, її здатнiсть розвиватися й протистояти новим загрозам IБ.

Сервiси безпеки повиннi забезпечувати чотири рiвнi захисту:

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

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

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

92

Приклади побудови захищених iнформацiйних технологiй

93

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

До необхiдного мiнiмуму для захисту Iнтранету варто вiднести реалiзацiю сервiсiв безпеки на мережному й транспортному рiвнях стека протоколiв TCP/IP i пiдтримку механiзмiв автентифiкацiї, стiйких до мережних загроз.

Для сервiсiв безпеки повинен дотримуватися принцип простоти їхнього використання. Вiн нацiлений на те, щоб зробити роботу сервiсiв безпеки прозорої для користувачiв. Повнiстю домогтися цього, звичайно, неможливо (наприклад, без автентифiкацiї за участю користувача не обiйтися), але якийсь порiг складностi перевищувати не можна. Користувачi сама слабка ланка будь-якої системи, i чим менше вони повиннi (i можуть) зробити, тим краще. Важливiсть цього принципу доведена всiм ходом розвитку iнформацiйних технологiй, кризами програмування, невдачами при створеннi бiльших систем. Повною мiрою принцип ставиться й до пiдсистеми безпеки, причому на всiх рiвнях вiд реалiзацiї окремих функцiй до об’єднання сервiсiв. Варто прагнути до мiнiмiзацiї числа зв’язкiв мiж компонентами IС, оскiльки саме воно визначає складнiсть. Загалом кажучи, iз принципом простоти конфлiктує необхiднiсть внесення в систему певної надмiрностi, що забезпечує стiйкiсть стосовно збоїв i вiдмов. По цiлому рядi причин реальний захист ресурсiв Iнтранет виявляється результатом численних компромiсiв.

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

94

Розд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в.

6.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д англ. Single Sign-On, SSO).

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

Починаючи з Windows 2000 в ОС Microsoft пiдтримується Kerberos [93] вiдкритий протокол автентифiкацiї (визначений в RFC 1510, випущеному Internet Engineering Task Force), за допомогою якого комп’ютер, що збирається встановити зв’язок з iншим комп’ютером, може пiдтвердити свою "особистiсть". Пiсля пiдтвердження Kerberos постачає обидва комп’ютери ключами шифрування для проведення захищеного сеансу зв’язку. Автентифiкацiя за допомогою Kerberos являє собою тристороннiй процес,

Приклади побудови захищених iнформацiйних технологiй

95

у якому роль посередника виконує сервiс за назвою Key Distribution Center (KDC), що пiдтверджує особистiсть комп’ютера по запитi iншого комп’ютера й поставляющий ключiв для встановлення мiж ними захищеного з’єднання. Кожний з комп’ютерiв, що беруть участь у сеансi зв’язку, "дiлить секрет"з KDC, що складається iз двох компонентiв: сервера автентифiкацiї й сервера видачi квиткiв. Якщо KDC одержує запит про невiдомому йому серверi призначення, вiн перенаправляє автентифiкацiйну транзакцiю на iнший KDC, що розташовує потрiбними вiдомостями.

Обмiнюючись iз клiєнтом серiєю шифрованих повiдомлень, називаних квитками, KDC генерує новi ключi шифрування для кожного етапу процесу автентифiкацiї. Вiн може успiшно пiдтвердити особистiсть одного комп’ютера по запитi iншого, не видаючи секретних ключiв нi однiєї зi сторiн i не вимагаючи нi вiд однiєї з них постiйного зберiгання ключiв доступу до всiх комп’ютерiв, з якими вони коли-небудь, установлять з’єднання. Квиток дiйсний протягом заданого перiоду часу й може використатися тiльки одним певним комп’ютером для пiдключення до iншого певного комп’ютера. Пiсля видачi квитка клiєнт може використати його для одержання доступу до цiльового сервера необмежене число раз, але тiльки в перiод дiї квитка. Нi клiєнт, нi хтось iншої не можуть уважати або модифiкувати квиток, не зробивши його недiйсним.

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

Єдиний вхiд у мережу з однократною реєстрацiєю (SSO) це в першу чергу вимога зручностi для користувачiв. Якщо в корпоративнiй мережi багато iнформацiйних сервiсiв, що допускають незалежний обiг, то багаторазова iдентифiкацiя/автентифiкацiя стає занадто обтяжною. Завдяки системi SSO користувач, лише один раз пройшовши процедуру реєстрацiї, одержує доступ одночасно до ресурсiв своєї робочої станцiї й всiєї мережi вiдповiдно до своїх посадових обов’язкiв. Супровiд численних облiкових записiв i паролiв для кожного користувача збiльшує витрати й на системне адмiнiстрування.