Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Побудова захищених АС.
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
Не вказано
Кафедра:
Не вказано
Інформація про роботу
Рік:
2024
Тип роботи:
Посібник
Предмет:
Засоби захисту інформації
Частина тексту файла (без зображень, графіків і формул):
Побудова захищених AC
У розділі розглянуто основні принципи та методи побудови СЗІ, деякі аспекти захисту на різних стадіях створення АС та аналізу захищеності СЗІ.
Нагадаємо найбільш загальні якісні риси проблеми захисту інформації, які були наведені вище. Отже, вона характеризується:
невизначеністю, яка, в свою чергу, зумовлена наявністю «людського фактора», оскільки невідомо, хто, коли, де і яким чином може порушити безпеку об'єкта захисту;
неможливістю створення ідеальної системи захисту (СЗ), тобто може йтися тільки про той або інший ступінь забезпечення безпеки об'єктів захисту;
використанням при організації захисту вимог мінімальності ризику та мінімальності можливих витрат;
необхідністю організації захисту від усіх і всього.
Аналіз цих рис, а також широкого спектру можливих загроз інформації дає можливість сформулювати найбільш загальні принципи створення захищених АС, тобто принципи, якими доцільно керуватися при розробці і втіленні в життя СЗІ для певного класу АС. їх зручно подавати у вигляді двох груп: організаційні принципи та принципи реалізації СЗІ.
7.1. Організаційні принципи побудови СЗІ
Серед організаційних принципів відзначимо такі:
Принцип законності, тобто додержання всіх законодавчих та нормативних актів, які мають відношення до забезпечення інформаційної безпеки. Важко переоцінити важливість цього принципу, хоча додержуватися його дуже непросто, особливо зважаючи на недосконалість та відставання від життя нашого відповідного законодавства.
Принцип персональної відповідальності, відповідно до якого кожен співробітник підприємства, фірми або їхній партнер несе персональну відповідальність за збереження режиму безпеки в рамках своїх повноважень. СЗІ має будуватися таким чином, щоб при будь-яких порушеннях було чітко відоме або хоча б мінімізоване коло осіб, що мають відношення до порушень. Це не тільки полегшує процес розслідування порушень, а також є ефективним засобом
сумлінного виконання службових обов'язків і утримання потенційних ЗЛ від несанкціонованих дій.
Принцип обмеження повноважень, який має відношення як до персоналу, так і до засобів захисту та обробки інформації; відповідно до нього, по-перше, ніхто не повинен знайомитись із конфіденційною інформацією, якщо це не потрібно для виконання його службових обов'язків; по-друге, повинна бути реалізована заборона на фізичний доступ до вразливих об'єктів для осіб, яким це не потрібно за родом їхньої діяльності; по-третє, для виконання функціональних обов'язків персоналу слід надавати мінімум будь-яких засобів.
Принцип взаємодії та співпраці усіх служб АС, спрямований на створення в АС сприятливої внутрішньої та зовнішньої атмосфери безпеки. Внутрішня атмосфера безпеки досягається довірчими відносинами між співробітниками СБ та персоналом, допоміжними заходами та стимулюванням, у тому числі і матеріальним. Діюча служба безпеки не повинна перетворюватися в засіб тотального стеження за персоналом з боку керівництва. В довірчій атмосфері набагато складніше подолати СЗІ. Створення зовнішньої атмосфери полягає в необхідності налагоджування співробітництва із зацікавленими особами та організаціями. Тобто йдеться про робочі контакти з місцевими органами влади, міліції, пожежної служби й іншими контролюючими організаціями, а також із службами безпеки сусідніх організацій - так створюються елементи колективної безпеки, що набагато підвищує її ефективність.
7.2. Принципи реалізації СЗІ
Реалізація СЗІ базується на принципах:
системності та комплексності;
централізованого управління СЗ;
неможливості обминути захисні засоби;
рівноміцності і рівнопотужності рубежів захисту;
ешелонованості оборони;
неможливості переходу до безпечного стану;
мінімальних привілеїв;
розподілу обов'язків;
простоти, гнучкості та керованості;
захисту засобів СЗ;
неперервності захисту;
розумної достатності;
відкритості алгоритмів та засобів захисту;
економічної ефективності СЗ.
Коротко пояснимо зміст наведених принципів.
Системність та комплексність включають необхідність урахування усіх елементів, умов і чинників, які є взаємозалежні, взаємодіють і змінюються в часі, а також є істотно значимі для розуміння і
вирішення проблеми забезпечення безпеки АС. При створенні системи захисту необхідно враховувати всі слабкі, найбільш вразливі місця системи обробки інформації, а також характер, можливі об'єкти і напрямки атак на систему з боку порушників (особливо висококваліфікованих зловмисників), шляхи проникнення в АС і НСД до інформації. У розпорядженні фахівців з комп'ютерної безпеки є широкий спектр заходів, методів і засобів захисту комп'ютерних систем. їх комплексне і використання передбачає узгоджене застосування різнорідних засобів при побудові цілісної системи захисту, що перекриває всі відомі канали реалізації загроз і не містить слабких місць на стиках окремих її компонентів.
Централізоване управління СЗ необхідно планувати внаслідок наявності в будь-якій АС цілого комплексу різнорідних технічних і нетехнічних заходів і засобів захисту АС. Крім того, централізоване управління дозволяє відстежувати виконання прийнятої ПБ.
Неможливість обминути захисні засоби полягає в тому, що внаслідок якісного та надійного інформаційного обстеження АС повинна бути впевненість у відсутності різного роду «обхідних шляхів» захисних засобів.
Рівноміцність і рівнопотужність рубежів захисту передбачають виявлення в рубежах захисту незахищених (або слабозахищених) ділянок і планування посилення найслабкішої ланки, а також однакового відносного рівня захищеності кожного рубежу захисту - більш потужний захист там, де більша загроза, і менш потужний у протилежному випадку. Крім того, рівноміцність передбачає найбільш ефективний розподіл захисних ресурсів по рубежах.
Ешелонованість оборони означає, що не слід покладатися на один захисний рубіж, яким би надійним він не здавався. За засобами фізичного захисту повинні слідувати програмно-технічні засоби, за ідентифікацією та автентифікацією - управління доступом і т. п. Засоби захисту на рівні ОС повинні забезпечувати одну з найбільш укріплених ліній оборони, оскільки ОС - це саме та частина КС, яка керує використанням усіх її ресурсів. Зовнішній захист повинен
Забезпечуватися фізичними, організаційними і правовими засобами. Неможливість переходу до безпечного стану передбачає, що за будь-яких обставин, в тому числі і нештатних, захисний засіб або виконує свої функції, або повністю блокує доступ. Образно кажучи,
такий стан має бути подібним до наступного: якщо в фортеці механізм підйомного мосту ламається, то міст має залишатися в піднятому стані. Принцип мінімальних привілеїв наказує виділяти персоналу тільки ті права доступу, які необхідні йому для виконання службових обов'язків, зменшуючи тим самим збитки від випадкових або навмисних некоректних дій персоналу.
Принцип розподілу обов'язків передбачає такий розподіл ролей і відповідальності, щоб лише одна людина не могла порушити
і
критично важливий для організації процес або створити пролом у захисті на замовлення зловмисника. Зокрема, його реалізація може попередити зловмисні або некваліфіковані дії персоналу.
Простота означає, що механізми захисту повинні бути інтуїтивно зрозумілі і прості у використанні. Застосування засобів захисту не повинно бути пов'язане зі знанням спеціальних мов або виконанням дій, що вимагають значних додаткових трудовитрат при звичній роботі законних користувачів, а також не повинно вимагати від користувача виконання рутинних малозрозумілих йому операцій (наприклад, запровадження декількох паролів та імен і т. п.). Крім того, простота дає можливість формально або неформально доводити коректність захисту.
Майже завжди вжиті заходи і встановлені засоби захисту, особливо в початковий період їхньої експлуатації, можуть забезпечувати як надмірний, так і недостатній рівень захисту. Природно, що для забезпечення можливості варіювання рівня захищеності засоби захисту повинні мати певну гнучкість. Особливо важливою ця властивість є в тих випадках, коли встановлення засобів захисту необхідно здійсню вати на працюючій системі, не порушуючи процесу її нормального функціонування. Крім того, зовнішні умови і вимоги з часом змінюють ся. В таких ситуаціях властивість гнучкості може врятувати власники АС від необхідності вжиття кардинальних заходів для повної заміни засобів захисту на нові. Керованість дозволяє перевіряти узгодженості конфігурацій різних компонентів і здійснювати централізоване адміністрування.
Принцип захисту засобів СЗ вимагає, щоб будь-який захисний захід або засіб був, у свою чергу, забезпечений захистом. При цьому; в основі принципу повинні лежати правила: «захист від усіх», «все що незрозуміле - небезпечне», «довіряй, але перевіряй».
Неперервність захисту означає, що захист інформації - це не разовий захід і навіть не певна сукупність проведених заходів і встановленого засобу захисту, а безперервний цілеспрямований процес що передбачає вжиття відповідних заходів на всіх етапах життєвого циклу АС, починаючи з ранніх стадій проектування, а не тільки на етапі її експлуатації. Розробка СЗ повинна вестися паралельно з розробкою самої АС. Це дозволить врахувати вимоги безпеки при проектуванні архітектури і, у кінцевому рахунку, дозволить створити більш ефективну (як за затратами ресурсів, так і за невразливістю) захищену систему. Більшості фізичних і технічних засобів захисту для ефективного виконання своїх функцій необхідна постійна організаційна (адміністративна) підтримка (своєчасна зміна і забезпечення правильного збереження і застосування імен, паролів, ключів шифрування, перевизначення повноважень і т. ін.). Перерви в роботі засобів захисту можуть бути використані ЗЛ для аналізу застосованих методів і засобів захисту; для впровадження спеціальних програмних і апаратних «закладок» і інших засобів подолання СЗ після відновлення її функціонування.
Розумна достатність передбачає, що створити абсолютно непереборну СЗ принципово неможливо - при достатній кількості часу і засобів можна перебороти будь-який захист. Однак високоефективна СЗ коштує дорого, використовує при роботі суттєву частину потужності і ресурсів КС і може створювати істотні додаткові незручності користувачам. Отже, СЗ має бути організована ефективно, тобто обсяг застосованих заходів повинен бути розумним і відповідати існуючим загрозам. Відкритість алгоритмів та засобів захисту полягає в тому, що застосовані для організації захисту методи, алгоритми та інші засоби не обов'язково мають бути засекреченими. Наприклад, відкритість алгоритму роботи СЗ не повинна давати можливість подолати її (навіть його автору). Як показує досвід, засекреченість розробок із захисту аж ніяк не підвищує рівень захищеності системи, а іноді навіть провокує підвищену увагу до неї, фактично підвищуючи ризик подолання СЗ.
Економічна ефективність СЗ означає, що слід вести мову тільки про деякий прийнятний рівень безпеки. Він має досягатися мінімумом витрат, тобто важливо правильно обрати той достатній рівень захисту, при якому поточні економічні витрати, ризик і розмір можливих майбутніх витрат були б прийнятними.
7.3. Методи побудови захищених АС
Методи побудови захищених АС умовно можна розділити на дві групи [6]:
1) що стосуються довільного ПЗ АС: ієрархічний метод розробки; дослідження коректності і верифікація.
2) специфічні тільки для систем захисту (теорія безпечних систем). Спочатку розглянемо ієрархічний метод розробки ПЗ АС. Відповідно до принципу абстракції при проектуванні АС розробники можуть іти щонайменше двома шляхами: від апаратури «вгору» - до віртуальної машини, яку являє собою АС, чи від віртуальної машини «униз» - до реального устаткування. Це і є два основні методи проектування - метод знизу вгору і метод зверху вниз. Інші методи по своїй суті зводяться до цих двох чи є їх комбінацією. Метод знизу вгору передбачає початок проектування з основного апаратного устаткування системи. При проектуванні модулі розбиваються на ряд шарів, причому нульовий шар віртуальної системи утворює апаратура. Шари, що реалізують одну чи кілька необхідних властивостей, додаються послідовно, поки не буде отримана бажана віртуальна машина.
До недоліків методу проектування знизу вгору відносять: • необхідність із самого початку приймати рішення про вибір способу реалізації компонентів АС - за допомогою апаратури, мікропрограм чи програм,- який зробити дуже важко; • можливість проектування АС тільки після розробки апаратури;
• розбіжність між реальною АС і визначеною в ТЗ.
При використанні методу зверху вниз (ієрархічний метод) виходять від віртуальної машини, що представляє АС, з необхідними властивостями і послідовно розробляють шари віртуальної системи апаратури. У цьому випадку проектування відбувається в такій послідовності. Визначається рівень абстракції опису компонентів АС вищого шару. Далі систематично проводиться аналіз того, чи достатньо визначені компоненти, щоб можна було їх реалізувати, використовуючи деякі примітивні поняття. Якщо ні, то кожна функція кожного компонента представляється функціями компонентів наступного шару, якому відповідає більш низький рівень абстракції, і знову проводиться аналіз на можливість їхньої реалізації. В ієрархічному методі доцільно використовувати структурний принцип і принцип модульного проектування.
Структурний принцип має фундаментальне значення і є основою більшості реалізацій. Відповідно до цього принципу, для побудови ПЗ вимагаються тільки три основні конструкції:
функціональний блок;
конструкція узагальненого циклу;
• конструкція ухвалення двоїчного рішення. Функціональний блок можна представити як окремий обчислювальний оператор чи як будь-яку іншу реальну послідовність обчислень з єдиним входом і єдиним виходом, як у підпрограмі. Організація циклу в літературі часто згадується як елемент DO-WHILE. Конструкція ухвалення двоїчного рішення називається IF-THEN-ELSE.
Зауважимо, що ці конструкції можуть самі розглядатися як функціональні блоки, оскільки вони мають тільки один вхід і один вихід. Таким чином, можна ввести перетворення операції циклу у функціональний блок і в подальшому розглядати всякий такий оператор циклу еквівалентом (трохи більш складного) функціонального блоку. Аналогічно можна ввести перетворення конструкції ухвалення рішення до функціонального блоку. Нарешті, можна привести будь-яку послідовність функціональних елементів до одного функціонального елемента. У той же час зворотна послідовність перетворень може бути використана в процесі проектування програми за спадною схемою, тобто виходячи з єдиного функціонального блоку, що поступово розкладається в складну структуру основних елементів.
Принцип модульного проектування полягає в поділі програм на функціонально самостійні частини (модулі), що забезпечують замінність, кодифікацію, видалення і доповнення складових.
Переваги використання модульного принципу такі:
• спрощується налагодження програм, тому що обмежений доступ до модуля й однозначність його зовнішнього прояву виключають вплив помилок в інших, зв'язаних з ним, модулях на його функціонування;
забезпечується можливість організації спільної роботи великих колективів розробників, тому що кожен програміст має справу з незалежною від інших частиною програми;
підвищується якість програми, тому що відносно малий розмір модулів і, як наслідок, невелика складність їх дають змогу провести більш повну перевірку програми.
Іншою проблемою є дослідження коректності реалізації і верифікація АС. Під поняттям коректності чи правильності розуміється відповідність об'єкта, що перевіряється, певному еталонному об'єкту чи сукупності формалізованих еталонних характеристик і правил. Коректність ПЗ при розробці найбільш повно визначається ступенем відповідності висунутим до неї формалізованим вимогам програмної специфікації. У специфікаціях відбивається сукупність еталонних характеристик, властивостей і умов, яким повинна відповідати програма. Основну частину специфікації складають функціональні критерії і характеристики. Вихідною програмною специфікацією, якій повинна відповідати програма, є ТЗ. У разі відсутності такої цілком формалізованої специфікації вимог, як ТЗ, якому повинна відповідати АС і результати її функціонування, іноді використовуються неформалізовані представлення розробника чи користувача-замовника програм. Однак поняття коректності програм стосовно запитів користувача чи замовника пов'язане з невизначеністю самого еталона, якому повинна відповідати АС. Для складних програм завжди існує ризик знайти їхню некоректність (на думку користувача чи замовника) при формальній коректності щодо специфікацій унаслідок неточності самих специфікацій. Традиційний погляд на специфікацію вимог полягає в тому, що І вона являє собою документ, написаний природною мовою, що є інтерфейсом між замовником і виготовлювачем. Хоча підготовці документа може передувати деяка взаємодія, саме цей документ значною мірою виступає як «точка відліку» для виготовлювача програм. Таким чином, можна зробити висновок про те, що створення сукупності взаємопов'язаних несуперечливих специфікацій є необхідною базою для забезпечення коректності проектованої програми. При цьому специфікації повинні: • бути формальними;
• дозволяти перевіряти несуперечність і повноту вимог замовника; • бути основою для подальшого формалізованого проектування ОС. Існує кілька підходів до визначення специфікацій вимог.
Специфікація як опис. Замовник видає специфікацію, щоб виробники могли постачити його тим виробом, що він бажає, тому замовник бачить цей документ головним чином як опис системи, яку він
бажав би мати. У принципі, в описі має бути зазначено, що повинна і Що не повинна робити система. На практиці звичайно по умовчанню передбачається, що система повинна робити те, що уточнюється в
специфікації, і не повинна робити нічого іншого. У цьому полягає головна проблема з описовою стороною специфікації. Передбачається, що замовник завжди точно знає все, що система повинна і не повинна робити. Більше того, надалі передбачається, що замовник цілком переніс це знання у специфікований документ.
Специфікація як розпорядження. Виробник дивиться на специфікований документ як на набір складових, що підлягають збиранню, щоб розв'язати проблему замовника. Такий директивний підхід обумовлюється не тільки труднощами створення описового документа (як зазначалося вище), а й відомостями, що навмисно чи ненавмисно розширюють чи обмежують волю виробника.
Договірна методологія. У рамках «опис замовника - розпорядження виробнику» специфікація розглядається як формальний поділ між сторонами. Що стосується замовника, то він обумовлює мінімально прийнятне, тоді як виготовлювач - максимально необхідне. Договір пропонується і приймається при зародженні системи і закінчується після завершення системи, коли замовник приймає систему, яка відповідає його мінімальним вимогам. Під час виготовлення системи в принципі не передбачається ніяких взаємодій, навіть якщо виробник підозрює, що наказуване не зовсім відповідає тому, що замовник бажає бачити насправді.
Специфікація як модель. Сучасні більш строгі уявлення про специфікацію трактують її як модель системи. За умови, що покладена в основу моделі семантика достатньою мірою обґрунтована, така специфікація забезпечує чітке формулювання вимог.
Відповідні моделі підходять також для автоматизованого контролю цілісності й іншого прогнозного аналізу, що, зокрема, забезпечить припинення розробки системи, у принципі не здатної задовольнити вимоги.
Моделі як опис системи мають такі відмітні риси порівняно з іншими способами формального опису:
добре сполучення спадного і висхідного підходів до їхньої розробки з можливістю вибору абстрактного опису;
можливість опису рівнобіжної, розподіленої і циклічної роботи;
можливість вибору різних формалізованих апаратів для опису систем.
Основна перевага використання формальної моделі полягає в можливості дослідження з її допомогою особливостей системи, що моделюється. Покладаючи в основу формального методу розробки математичну модель і потім досліджуючи модель, можна виявити такі грані поводження системи, що в іншому разі не були б очевидні до більш пізніх стадій.
Оскільки цільовим об'єктом проектування є АС, то модель може описувати або саму АС, або її поводження, тобто зовнішні прояви функціонування АС. Модель, що описує поводження АС у порівнянні з моделлю АС, має одну важливу перевагу - вона може бути перевірена й
оцінена як виконавцями, так і замовниками, оскільки замовники не знають, як повинна працювати АС, але зате вони уявляють, що вона повинна робити. У результаті такого моделювання може бути перевірена коректність специфікацій щодо вихідної постановки задачі, тобто ТЗ. Крім того, критерії правильності вважаються достатніми за умови, що специфікація являє собою вичерпний опис «зовнішнього» поводження об'єкта в усіх можливих (чи запланованих) ситуаціях його використання.
Як було відзначено вище, при розробці АС, особливо її компонентів, що представляють СЗІ, для забезпечення високих гарантій відсутності несправностей і наступного доказу того, що система функціонує відповідно до вимог ТЗ, використовуються формальні підходи до її проектування.
Формальне проектування алгоритмів базується, в основному, на мовах алгоритмічних логік, що включають висловлення виду
Q{S}R,
що читається в такий спосіб: «якщо до виконання оператора S була виконана умова Q, то після нього буде R». Тут Q називається передумовою, a R - постумовою. Ці мови були винайдені практично одночасно Р. У. Флойдом (1967 p.), С. А. Р. Хоаром (1969 р.) і вченими
польської логічної школи (А. Сальвіцький та ін., 1970 p.). Як передумова, так і постумова є предикатами.
Розгляд програм як деяких «перетворювачів предикатів» дає змогу прямо визначити зв'язок між початковими і кінцевими станами без яких-небудь посилань на проміжні стани, що можуть виникнути під
час виконання програми.
Перевага представлення алгоритму у вигляді перетворювача предикатів полягає в тому, що воно дає можливість:
• аналізувати алгоритми як математичні об'єкти;
• дати формальний опис алгоритму, що дозволяє інтелектуально
охопити алгоритм;
• синтезувати алгоритми за представленими специфікаціями;
• провести формальне верифікування алгоритму, тобто довести коректність його реалізації.
Методологія формальної розробки і доведення коректності в даний час добре розроблена і викладена в цілому ряді робіт. Коротко
викладемо суть цих методів:
• розробка алгоритму проводиться методом послідовної декомпозиції, з розбивкою загальної задачі, розв'язуваної алгоритмом, на ряд дрібніших підзадач;
• критерієм деталізації підзадач є можливість їхньої реалізації за допомогою однієї конструкції чи розгалуження циклу;
• розбивка загальної задачі на підзадачі передбачає формулювання перед- і постумов для кожної підзадачі з метою їхнього коректного проектування і подальшої верифікації.
Для доведення коректності алгоритму (верифікація) формулюється математична теорема Q{S}R, що потім доводиться. Доведення теореми про коректність прийнято розбивати на дві частини. Одна частина служить для доведення того, що розглянутий алгоритм може завершити роботу (проводиться аналіз усіх циклів). В іншій частині доводиться коректність постумови в припущенні, що алгоритм завершує роботу.
Дуже важливим напрямком є теорія довірених безпечних систем (ТСВ). Поняття «довірене обчислювальне середовище» (trusted computing base - ТСВ) з'явилося у закордонній практиці забезпечення інформаційної безпеки досить давно. Зміст характеристики «довірена» можна пояснити в такий спосіб.
Дискретна природа характеристики «безпечний» (у тому сенсі, що або щось є безпечним, цілком задовольняючи ряд пропонованих вимог, або не є, якщо одна чи кілька вимог не виконані) у сполученні з твердженням «ніщо не буває безпечним на сто відсотків» підштовхують до того, щоб увести більш гнучкий термін, який дає можливість оцінювати те, наскільки розроблена захищена АС відповідає очікуванням замовників. У цьому відношенні характеристика «довірений» більш адекватно відбиває ситуацію, де оцінка, виражена цією характеристикою (безпечний чи довірений), грунтується не на думці розробників, а на сукупності факторів, включаючи думку незалежної експертизи, досвід попереднього співробітництва з розробниками, і, в остаточному підсумку, є прерогативою замовника, а не розробника.
Довірене обчислювальне середовище (ТСВ) включає сукупність усіх компонентів і механізмів захищеної АС, що відповідають за реалізацію політики безпеки. Всі інші частини АС, а також її замовник покладаються на те, що ТСВ коректно реалізує задану політику безпеки навіть у тому випадку, якщо окремі модулі чи підсистеми АС розроблені висококваліфікованими ЗЛ для того, щоб втрутитися у функціонування ТСВ і порушити підтримувану нею політику безпеки.
Мінімальний набір компонентів, що утворюють довірене обчислювальне середовище, забезпечує такі функціональні можливості:
взаємодію з апаратним забезпеченням АС;
захист пам'яті;
функції файлового виведення-введення-висновку;
керування процесами.
Доповнення і модернізація існуючих компонентів АС з урахуванням вимог безпеки можуть призвести до ускладнення процесів супроводу і документування. З іншого боку, реалізація всіх перелічених функціональних можливостей у рамках централізованого довіреного обчислювального середовища в повному обсязі може викликати розростання розмірів ТСВ і, як наслідок, ускладнення доведення коректності реалізації політики безпеки. Так, операції з файлами можуть бути реалізовані в ТСВ у деякому обмеженому обсязі, достатньому для підтримки політики безпеки, а розширене введення-виведення у
такому випадку реалізується в тій частині АС, що перебуває за межами ТСВ. Крім того, необхідність упровадження пов'язаних з безпекою функцій у багато компонентів АС, які реалізовані в різних модулях АС, призводить до того, що захисні функції розподіляються по всій АС, викликаючи аналогічну проблему.
7.4. Передпроектні аспекти створення СЗІ
У процесі проектування захищеної АС необхідно проектувати і СЗІ, причому потрібно враховувати два основні параметри: стан АС і рівень витрат на створення АС. Щодо стану АС, то слід зазначити, що під станами АС маються на увазі такі ситуації: АС уже функціонує, є готовий проект, система тільки проектується. Витрати ж можна задавати або поки що вважати їх необмеженими. Таким чином, глобальне завдання створення СЗІ - це створення оптимальних механізмів захисту і управління ними. Цю загальну мету можна виразити у вигляді послідовності наступних дій або концепції захисту:
аналіз цілей і умов проектування;
обґрунтування вимог до ЗІ; • вибір варіанта проекту;
• реалізація варіанта проекту.
Як обґрунтувати вимоги до ЗІ? Тут слід зазначити, що формальних методів розв'язання цієї задачі не існує і її доводиться розв'язу
вати неформально, у вигляді деяких рекомендацій, пропозицій і т. п., ; які формуються на основі наведених вище принципів. Складно, користуючись лише інженерною інтуїцією, одержати оптимальні проектні рішення. Часто доводиться залучати досить і складні наукові методи, що вимагають розробки і застосування комп'ютерних систем.
Нижче розглядається приклад можливої послідовності дій щодо створення захищеної АС [27].
Отже, загальні цілі і задачі для даного об'єкта звичайно визначаються в процесі діалогу замовника і проектанта. У ході розробки проекту вони постійно будуть уточнюватися, тобто в процесі спільної роботи підвищується взаєморозуміння замовника і проектанта і шукається розумний компроміс.
На передпроектних стадіях робіт зі створення АС повинні бути вирішені два такі основні завдання:
• сформульовано вимоги до забезпечення режиму ІБ при реалізації функцій і задач проектованої АС;
• розроблено концепцію політики ІБ.
Важливо відзначити те, що вимоги формулюються щодо задач і функцій у термінах:
• доступності (період недоступності, час доступу, інші показники, обумовлені предметною областю);
цілісності (показники надійності збереження, доставки);
конфіденційності (градації конфіденційності чи грифів таємності). Розробка концепції політики ІБ відбувається на етапі «Розробка варіантів концепції АС і вибір варіанта концепції АС» після вибору варіанта концепції створюваної АС і здійснюється на основі аналізу таких груп факторів:
правові і договірні вимоги;
вимоги до забезпечення режиму ГБ щодо функцій і задач АС;
загрози (класи ризиків), яким піддаються інформаційні ресурси. У результаті аналізу формулюються загальні положення ІБ, що стосуються організації в цілому:
цілі і пріоритети, які має організація в області ІБ;
загальні напрямки в досягненні цих цілей;
• аспекти програми ІБ, що повинні зважуватися на рівні організації в цілому;
• посадові особи, відповідальні за реалізацію програми ІБ. Розробку самої політики ІБ варто здійснювати на стадії «Технічне завдання» і при цьому виконати такі етапи:
аналіз ризиків;
визначення вимог до засобів захисту;
вибір основних рішень щодо забезпечення режиму ІБ;
розробка планів забезпечення безперебійної роботи організації;
документальне оформлення політики ІБ. Розглянемо один за одним зазначені етапи.
Аналіз ризиків передбачає вивчення і систематизацію загроз ІБ, визначення вимог до засобів забезпечення ІБ. Вивчення і систематизація загроз ІБ передбачає такі етапи:
Вибір елементів АС і інформаційні ресурси, для яких буде застосовано аналіз. Повинні бути обрані критичні елементи АС і критичні інформаційні ресурси, що можуть бути об'єктами атаки чи самі є потенційним джерелом порушення режиму ІБ.
Ідентифікація загроз і формування їх списку. Формується детальний список загроз, складається матриця загрози/елементи АС чи інформаційні ресурси. До кожного елемента матриці потрібно скласти опис можливого впливу загрози на відповідний елемент АС чи інформаційний ресурс. У процесі складання матриці уточнюється список загроз і виділених елементів.
Розробка методології оцінки ризику. Повинні бути отримані оцінки гранично припустимого й існуючого ризику здійснення загрози протягом деякого часу. В ідеалі для кожної із загроз має бути отримане значення ймовірності її здійснення протягом деякого часу. Це допоможе співвіднести оцінку можливого збитку з витратами на захист. На практиці для більшості загроз неможливо одержати достовірні дані про ймовірність реалізації загрози і доводиться обмежуватися якісними оцінками.
Оцінка збитку, пов'язаного з реалізацією загроз. Здійснюється оцінка збитку, що може завдати діяльності організації реалізація загроз безпеки, з урахуванням можливих наслідків порушення конфіденційності, цілісності і доступності інформації.
Оцінка витрат на заходи, пов'язані із захистом і залишковим ризиком. Здійснюється попередня оцінка прямих витрат по кожному заходу без урахування витрат на заходи комплексного характеру.
Аналіз вартість/ефективність. Витрати на систему захисту інформації необхідно співвіднести з цінністю інформації, що захищається, й інших інформаційних ресурсів, що піддаються ризику, а також зі збитком, який може бути завдано організації внаслідок реалізації загроз. У результаті аналізу уточнюються припустимі залишкові ризики і витрати на заходи, пов'язані із захистом інформації.
Підсумковий документ. За результатами проведеної роботи складається документ, що містить:
переліки загроз ІБ, оцінки ризиків і рекомендації для зниження ймовірності їхнього виникнення;
захисні заходи, що необхідні для нейтралізації загроз;
аналіз вартість/ефективність, на підставі якого робляться висновки про припустимі рівні залишкового ризику і доцільність застосування конкретних варіантів захисту.
При визначенні вимог до засобів захисту вихідними даними є:
аналіз функцій і задач АС;
аналіз ризиків.
На основі цих даних обирається профіль захисту (клас захищеності АС від НСД) і у разі потреби в технічному завданні формулюються додаткові вимоги, специфічні (пов'язані, наприклад, зі специфікою ІБ у сучасних розподілених АС) для даної АС.
Для всіх функцій і задач АС потрібно дати визначення відповідних функцій безпеки. Функції безпеки з однаковими назвами можуть мати різні визначення для різних функцій і задач АС.
Потім визначаються механізми безпеки, що реалізують ці функції. Як відомо, основні механізми ІБ такі:
керування доступом до інформації;
ідентифікація й автентифікація;
криптографія;
екранування;
забезпечення цілісності і доступності даних;
підтримка працездатності АС при збоях, аваріях, НП;
відстеження подій, що становлять загрозу ІБ;
керування доступом в АС;
протоколювання дій і подій.
Вибір основних рішень щодо забезпечення режиму ІБ повинен бути розглянутий на трьох рівнях:
адміністративному (система підтримки керівництвом організації робіт із забезпечення ІБ);
організаційному (конкретні організаційні заходи щодо забезпечення режиму ІБ);
технічному (реалізація механізмів захисту програмно-технічними засобами).
7.5. Забезпечення режиму ІБ на подальших стадіях створення АС
Подальшими стадіями створення АС є «Ескізний проект» і «Технічний проект». На цих стадіях повинні бути розроблені проектні рішення, що реалізують механізми ІБ. Проектні рішення мають включати розділи:
основні технічні рішення по системі в цілому;
опис автоматизованих функцій і задач;
основні технічні рішення за видами забезпечення;
заходи щодо підготовки об'єкта автоматизації до введення системи в дію.
У процесі підготовки до експлуатації АС повинні бути вирішені питання навчання користувачів і персоналу, організації фізичного захисту і контролю за дотриманням режиму ІБ, організації доступу користувачів до роботи в АС.
Користувачів і персонал мають навчити дотриманню режиму ІБ, правильному поводженню з інформаційними ресурсами. Вони повинні знати про загрози порушення режиму ІБ і мати необхідні навички для роботи в АС. Рекомендується затвердити права й обмеження на доступ користувачам у письмовій формі.
Для організації фізичного захисту і контролю за дотриманням режиму ІБ повинні бути розглянуті такі питання.
Контроль доступу в приміщення. Контроль доступу в приміщення і загальні заходи для захисту устаткування є складовою заходів для забезпечення ІБ. Устаткування, критично важливі чи вразливі елементи системи, повинні бути розміщені в захищених ділянках, обмежених периметром безпеки, з належним контролем доступу в приміщення. Для зменшення ризику НСД чи ушкодження документації і носіїв інформації рекомендується задати правила використання робочого столу.
Забезпечення конфіденційності. Користувачі інформаційних ресурсів організації повинні підписати зобов'язання про збереження конфіденційності (нерозголошення). Особливу увагу варто приділити процедурі надання доступу до інформаційних ресурсів користувачам зі сторонніх організацій. Для цього повинні бути розроблені спеціальні правила.
Журнали реєстрації подій. Необхідно підготувати журнал реєстрації виконуваних завдань, що будуть вести оператори АС.
4. Забезпечення захисту документації по АС. Документація по АС може містити опис прикладних процесів, структур даних і процесів підтвердження повноважень. У цьому випадку вона повинна бути захищена від НСД. Рекомендується застосовувати такі засоби контролю:
список осіб із правом доступу до документації повинен бути максимально обмежений, а дозвіл на її використання має видаватися власником додатка;
друковані матеріали, створювані в процесі роботи АС, які стосуються документації, варто зберігати окремо від інших матеріалів і поширювати на них правила обмеження доступу.
5. Доступ до носіїв інформації і їхній захист. Необхідно організувати контроль доступу до носіїв інформації і забезпечити їхній фізичний захист. Для доступу до носіїв інформації з конфіденційною інформацією необхідно мати затверджені правила. При організації системи доступу слід враховувати таке:
система ідентифікації носіїв повинна бути така, щоб за мітками, використовуваними для ідентифікації носіїв, не можна було визначити, яка саме інформація зберігається;
необхідно вчасно стирати вміст повторно використовуваних носіїв інформації, якщо вони більше не потрібні;
винесення носіїв інформації зі сховища необхідно фіксувати в контрольному журналі;
збереження всіх носіїв інформації в надійному, захищеному місці відповідно до інструкцій.
На етапі підготовчої роботи з організації доступу в АС рекомендується розглянути такі питання.
1. Реєстрація користувачів. Повинні існувати документи з описом доступних користувачу сервісів, допустимих правил роботи в АС і правил забезпечення режиму ІБ. Сервіси АС не повинні надавати доступ, поки не будуть закінчені процедури визначення повноважень. Для керування доступом до багатокористувацьких сервісів має бути розроблена процедура реєстрації користувачів. Ця процедура повинна:
перевіряти, чи надано користувачеві дозвіл на використання сервісу відповідальним за його використання;
вести облік усіх зареєстрованих осіб, що використовують АС;
перевіряти, чи достатній рівень доступу користувача до системи і чи не суперечить він політиці безпеки, прийнятій в організації, наприклад, чи не компрометує він принцип поділу обов'язків;
вчасно вилучати права доступу в користувачів, що залишили організацію;
періодично перевіряти і видаляти застарілі ідентифікатори й облікові записи, що більше не потрібні.
2. Керування привілеями. Використання спеціальних привілеїв варто обмежити і контролювати, оскільки це один з основних факторів, Що сприяють порушенню режиму ІБ. У багатокористувацьких АС повинна існувати система контролю надання привілеїв. При організації такої системи рекомендується:
ідентифікувати привілеї, пов'язані з кожним програмним продуктом чи сервісом, підтримуваним системою, а також категорії співробітників, яким їх необхідно надати;
надавати привілеї окремим особам тільки у випадку крайньої необхідності і залежно від ситуації, тобто тільки коли вони потрібні для виконання ними своїх функцій;
реалізувати автоматичний процес визначення повноважень і вести облік усіх наданих привілеїв;
по можливості використовувати системні програми, для яких немає необхідності надавати спеціальні привілеї користувачам;
користувачі, що мають великі привілеї для спеціальних цілей, повинні використовувати інший ідентифікатор користувача для звичайної роботи.
3. Керування паролями користувачів. Надання паролів необхідно контролювати. Зразкові вимоги до системи контролю повинні бути такими:
зобов'язати користувачів зберігати персональні паролі і паролі робочих груп у секреті;
коли користувачі повинні самі вибирати свої паролі, видати їм надійні тимчасові паролі, що вони зобов'язані негайно замінити. Тимчасові паролі також видаються у випадку, коли користувачі забувають свої паролі;
передавати тимчасові паролі користувачам надійним способом. Варто уникати передачі паролів через посередників чи за допомогою незахищених (незашифрованих) повідомлень електронної пошти. Користувачі повинні підтвердити одержання паролів.
4. Перегляд прав доступу користувачів. Для забезпечення ефективного контролю за дотриманням режиму ІБ необхідно організувати процес перегляду прав доступу користувачів через регулярні проміжки часу. Такий процес має забезпечувати:
перегляд повноважень доступу користувачів через регулярні проміжки часу (наприклад, 6 місяців);
перегляд дозволу на надання спеціальних привілейованих прав доступу через більш короткі проміжки часу (наприклад, 3 місяці).
Підтримка режиму ІБ при експлуатації АС вимагає постійного контролю за реалізацією політики ІБ. Основними напрямками є контроль за роботою користувачів, захист цілісності даних і програм, керування доступом до додатків.
Контроль за роботою користувачів включає такі аспекти:
керування доступом до робочих місць в АС;
контроль за використанням паролів;
контроль за устаткуванням, залишеним без нагляду;
відстеження часу простою терміналів;
обмеження доступу до сервісів.
Користувачі повинні знати свої обов'язки щодо забезпечення контролю доступу, особливо що стосується використання паролів. Доступ користувача до ресурсів АС п...
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора