11.2. Основи заходів забезпечення високої доступності

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

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

• апробованість усіх процесів і складових частин інформаційної системи;

• уніфікація процесів і складових частин;

• керованість процесів, контроль стану частин;

• автоматизація процесів;

• модульність архітектури;

• орієнтація на простоту рішень.

Доступність системи в загальному випадку досягається за рахунок застосування трьох груп заходів, спрямованих на підвищення:

• безвідмовності (під пим розуміється мінімізація ймовірності виникнення якої-небудь відмови; це елемент пасивної безпеки, що далі розглядатися не буде);

• відмовостійкості (здатності до нейтралізації відмов, "живучості", тобто здатності зберігати необхідну ефективність, незважаючи на відмови окремих компонентів);

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

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

11.3. Відмовостійкість і зона ризику

Інформаційну систему можна уявити у вигляді графа сервісів, ребра якого відповідають відношенню "сервіс А безпосередньо використовує сервіс В".

Нехай у результаті здійснення деякої атаки (джерелом якої може бути як людина, так і природне явище) виводиться з ладу підмножина сервісів В| (тобто ці сервіси в результаті нанесених ушкоджень стають непрацездатними). Назвемо Б і зоною поразки.

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

Щоб система не містила одиночних крапок відмови, тобто залишалася "живучою" при реалізації кожної з розглянутих загроз, жодна зона ризику не повинна містити в собі надавані послуги. Нейтралізацію відмов потрібно виконувати усередині системи, непомітно для користувачів, за рахунок розміщення достатньої кількості надлишкових ресурсів. З іншого боку, природно порівнювати зусилля по забезпеченню "живучості" з розглянутими загрозами. Коли розглядається набір загроз, що відповідають ним, зони поразки можуть виявитися вкладеними, так що "живучість" стосовно більш серйозної загрози автоматично спричиняє й "живучість" у більш простих випадках. Варто враховувати, однак, що звичайно вартість перемикання на резервні ресурси зростає разом зі збільшенням обсягу цих ресурсів. Виходить, що для найбільш ймовірних загроз доцільно мінімізувати зону ризику, навіть якщо передбачено нейтралізацію всеохоплюючої загрози. Немає сенсу перемикатися на резервний обчислювальний центр тільки тому, що в одного із серверів вийшов з ладу блок живлення.

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

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

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