Впровадження технічних засобів безпеки в мережі операторів

Наприклад , в high - end масивах Hitachi RAID - група складається з 4 -х або восьми дисків , де кожен диск підключається до двох різних петель від двох різних дисків контролерів. Така конфігурація дозволяє виконувати операції запису-читання з усіх дисків RAID- групи паралельно , чого не можна домогтися в mid - range масивах , коли диски однієї RAID- групи розташовані вздовж однієї петлі і доступ до них здійснюється по черзі.

( 1 ) Іноді ще для high - end масивів говорять про " cache - centric " архітектуру , підкреслюючи тим самим , що центральною ланкою є кеш -пам'ять , до якої мають доступ усі контролери масиву , тоді як в mid - range масивах кеш -пам'ять жорстко прив'язана до певного контролеру .

Зазначені відмінності в архітектурі призводять до втрати продуктивності при масштабування mid - range масивів , чого не спостерігається у high - end масивів при додаванні нових дисків. Хоча сучасні mid - range масиви мають високі характеристики масштабованості : дозволяють встановлювати до двох- трьох сотень дисків , розподіляючи їх по декількох FC -AL петель , а також нарощувати кеш- пам'ять до 8 ГБ , все ж " вузьким місцем" залишається їх архітектура , яка є обмежувачем масштабованості .

Якщо дотримуватися зазначеної класифікації , то тільки масиви HDS сімейства 9900 і масиви EMC сімейства Symmetrix можна віднести до класу high - end .



Рисунок 13.Коммутаційна архітектура high-end масиву на прикладі HDS Lightning 9900V

Масиви HP EVA і IBM ESS 800 ( Shark ) , які позиціонуються виробниками як high - end масиви , мають архітектуру , типову для mid - range масивів .

На закінчення про віртуалізацію

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

Цей пул вже , в свою чергу , " нарізається " на логічні ( віртуальні ) диски ( LogicalUnitNumber - LUN ) , які " видно" серверам як фізичні . Насправді подібну організацію дискової пам'яті давно вже дозволяє створювати менеджер томів VERITAS VolumeManager . Даний тип віртуалізації отримав назву " host - based " віртуалізація .Практично всі сучасні дискові масиви виконують функцію створення з наборів фізичних дисків логічних дисків ( LUN ) , що отримала назву " diskarray - based " віртуалізація . Це легко визначити на підставі того факту , що ряд масивів підтримують число LUNs більше, ніж фізичних дисків, як , наприклад , в недавно анонсованому масиві SunStorEdge 3510 . Питання полягає в тому , наскільки це зручно. Адміністратори воліють мати можливість керувати фізичним розміщенням файлів даних СУБД ORACLE по фізичних дискам для досягнення оптимальної продуктивності та відмовостійкості . Налаштування СУБД під оптимальну продуктивність може стати проблематичною , якщо контролер дискового масиву не дозволяє управляти розміщенням RAID- груп на конкретних дисках.

Крім зазначених двох типів віртуалізації - " host - based " і " diskarray - based " , існує ще один тип - "SAN - based " . У цьому типі віртуалізації приховування від серверів фізичного розташування даних здійснюється або за допомогою спеціальних пристроїв , розташованих між FC- комутаторами SAN ( " in - band " віртуалізація ), або засобами самих FC- комутаторів , що зчитують інформацію про конфігурацію віртуального дискового простору з зовнішнього пристрою ( " out - off - band " віртуалізація ) .В даний час продуктів " SAN - based " віртуалізації на ринку мало і говорити про їх промисловому впровадженні поки не доводиться. Можливо , потреба в цьому типі віртуалізації з'явиться тоді , коли обсяги даних підприємств зростуть настільки , що для їх оперативного зберігання не вистачатиме кількох high - end дискових масивів .

6. Системний аналіз вразливостей і підбір механізмів їх усунення

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

Таблиця 3.1 - Зведена таблиця вразливостей сервера резервного копіювання мережевої файлової

Група загроз	Уразливість	Усунення
1	2	3
Фізичні загрози для сервера резервного копіювання мережевої файлової системи	Відсутність контролю доступу в приміщення, де знаходиться сервер резервного копіювання.	Установка системи контролю доступом
	Незахищене зберігання носіїв з резервною копією даних	Зберігання носіїв з резервною копією даних у сейфі
	Бездоглядна робота зовнішнього персоналу або персоналу, що працює в неробочий час	Встановлення системи відео спостереження
Загрози несанкціонованого доступу	Відсутність механізмів аутентифікації і ідентифікації	Налаштування в ОС ідентифікації і аутентифікації користувачів
	Дані на носіях зберігаються у відкритому вигляді	Використання засобів криптографічного захисту інформації
	Помилки в операційній системі, ПЗ	Установка антивірусних програм, своєчасна установка оновлень
	Наявність в програмному забезпеченні не позначених в документації можливостей	Використання сертифікованого ПЗ
Нецільове використання сервера резервного копіювання мережевої файлової системи співробітниками організації.	Відсутність політики поділу обов'язків або їх невиконання	Введення політики поділу обов'язків, та відповідальності за їх невиконання
Загрози недоступності сервера резервного копіювання і руйнування (втрати) інформації.	Місце, в якому знаходиться сервер резервного копіювання не обладнане належним чином	Обладнання приміщення джерелами безперебійного живлення, системою охолодження, пожежної сигналізація і т.д.
	Відсутність контролю над носіями, використання застарілого, що не надійного обладнання	Резервні копії повинні регулярно тестуватися, щоб бути впевненим у їх працездатності
	Системні збої або помилки ПО	Своєчасне оновлення ОС і ПО
Загрози порушення цілісності та несанкціонованої модифікації даних	Ненавчений персонал	Проведення інструктажів
	Відсутність засобів контролю цілісності даних	Установка і використання засобів контролю цілісності даних
Загрози підміни довіреної об'єкта в мережі	Відсутність коштів перевірки автентичності мережевих адрес	Установка міжмережевого екрану

6.1 Типова сукупність програмних засобів для захисту сервера резервного копіювання мережевої файлової

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

1. Антивірусне програмне забезпечення.

2. Криптографічні засоби захисту і засоби контролю цілісності інформації.

3. Міжмережеві екрани

4. Програмні комплекси, що реалізують одразу кілька функцій по захисту інформації.

Після йде розгляд кожного пункту окремо.

Антивірусне програмне забезпечення.

Для вибору ефективної антивірусного захисту було виконано звернення до різних сайтів тестуючим дане ПЗ. Тут представлені результати тестування програмних комплексів, але оскільки антивірусні бази і методи виявлення вірусів однакові і для антивірусів, результати підходять для виконання поставленого завдання. Результати представлені в таблиці 3.1 та таблиці 3.2

Таблиця 3.2 - Тест антивірусів на лікування активного зараження

Тестуємий продукт	Кількість відображених атак	Кількість пропущених атак, відсутність самозахисту	Всього балів (max 33)
	Кількість повністю відображених атак	Кількість частково відображених атак
Kaspersky Internet Security 2011 1	33 2	0 3	0 4	33 5
ZoneAlarm Internet Security Suite 2010	32	0	1	32
Dr.Web Security Space 6.0	29	4	0	31
Comodo Internet Security 5.0	30	1	2	30,5
Outpost Security Suite Pro 2010 (7,0)	30	1	2	30,5
Norton Internet Security	27	6	0	30
BitDefender Internet Security 2011	27	5	1	29,5

Таблиця 3.3 - Тест самозахисту антивірусів

Антивірус \ зловмисне ПЗ	Dr.Web Security Space 6.0.5.04110	Kaspersky Internet Security 2011	Microsoft Security Essentials 2.0.657.0
TDL (TDSS, Alureon, Tidserv)	+	+	+
Koutodoor	+	+	-
Win32/Glaze	+	+	+
Sinowal (Mebroot)	+	+	-
Rootkit.Protector (Cutwail, Pandex)	+	+	+
Worm.Rorpian	+	+	-
Rootkit.Podnuha (Boaxxe)	+	+	+
Virus.Protector (Kobcka, Neprodoor)	+	+	-
Rustock (Bubnix)	-	+	+
Email-Worm.Scano (Areses)	+	+	-
SST (DNSChanger, FakeAV)	+	+	+
SubSys (Trojan.Okuks)	+	+	+
Rootkit.Pakes (synsenddrv, BlackEnergy)	+	+	+
TDL2 (TDSS, Alureon, Tidserv)	+	+	+
TDL3 (TDSS, Alureon, Tidserv)	+	+	+
TDL4 (TDSS, Alureon, Tidserv)	+	+	-
Xorpix (Eterok)	+	+	+
Виліковано/Всього	16/17	17/17	11/17

Виходячи з результатів тестів видно, що необхідний рівень захисту від вірусів забезпечують 2 програмних продукту: Dr.Web Security Space 6.0.5.04110 і Kaspersky Internet Security 2011, інші або пропускають атаки, або не можуть боротися з активним зараженням. Обидва вони є сертифікованими на території України.

Криптографічні засоби захисту і засоби контролю цілісності інформації.На жаль, аналіз існуючих на ринку програмних продуктів СКЗИ і контролю цілісності стосовно до шифрування резервних копій не дає можливості вибору. Єдиним його представником є ??Zbackup від фірми "SecureIt". До того ж, крім цього необхідно придбати модуль забезпечує шифрування за алгоритмом ГОСТ 28147-89. Відповідний модуль надається фірмою "Аканд" і має назву Crypton Emulator для Windows. Цей модуль має сертифікат ФСБ, що дозволяє використовувати цю систему для захисту персональних даних першої категорії.

Міжмережеві екрани.

Вибір програмного брандмауера аналогічно антивірусній програмі проведено на підставі тестування, результати якого наведені в таблиці 3.4, а для більш наочного уявлення і на рис. 3.1.



Таблиця 3.4 - Тест farewall на захист від внутрішніх атак

Тестуємий продукт	Варіант налаштувань	Запобігання атак, %	Всього, %
		Базовий рівень складності	Підвищений рівень складності
Comodo	Max	100%	100%	100%
DefenseWall	Untrusted Zone Max	100%	100%	100%
DefenseWall	Untrusted Zone Standard	100%	100%	100%
Comodo	Standard	97%	100%	98%
Kaspersky	Max	100%	83%	96%
PC Tools	Max	100%	72%	94%
Outpost	Max	98%	67%	91%
Online Armor	Max	92%	72%	88%
Online Armor	Standard	92%	72%	88%
Online Solutions	Max	92%	67%	86%
Online Solutions	Standard	92%	67%	86%
Outpost	Standard	89%	67%	84%
BitDefender	Max	81%	78%	80%

Явними лідерами тестування є міжмережеві екрани Comodo і DefenseWall, не далеко від них відстав і вітчизняний продукт Kaspersky. Але DefenseWall не сертифікований в РФ, тому з подальшого розгляду виключається.

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

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

Рисунок 14 - Тест farewall на захист від внутрішніх атак

Таблиця 3.5 - Уразливості і засоби захисту, що їх усувають

Уразливості	Засоби захисту
	Kaspersky Internet Security 2012	Антивірус Касперського 2012	Dr.Web Security Space	Comodo Firewall	Zbackup з модулем Crypton Emulator
Зберігання даних у відкритому вигляді	-	-	-	-	+
Використання вразливостей системи резервного копіювання або помилок в ПЗ	+	+	+	-	-
Відсутність засобу перевірки достовірності мережевих адрес 1	+ 2	- 3	- 4	+ 5	- 6
Ціна, грн.	478	334	290	0	50000

Вивчивши програмні засоби, виходить, що для закриття вразливостей необхідні два програмних продукту - це Kaspersky Internet Security 2012 і Zbackup з модулем Crypton Emulator. Загальна їх вартість дорівнює 50478 грн. Крім того, слід мати на увазі, що при захисті системи інформаційної передачі даних 2 класу і вище сертифікованим міжмережевим екраном є лише VipNet Firewall, вартість якого 14 000р, і тоді загальна сума буде дорівнює 212т.р.

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

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

Відповівши на ці питання можна визначити тип створюваної системи.

Таблиця 4.1 - Залежність надійності системи від її типу

№ п/п	Тип системи	Рівень надійності, %	Максимальний час простою	Типовий час простою за раз
1	Звичайна	99	3,5 суток в год	1-2 години
2	Висока надійність	99,9	8,5 часов в год	Менш 1 години
3	Відмовостійка	99,99	1 час в год	Декілька хвилин
4	Безвідмовна	99,999	5 минут в год	Декілька хвилин

Наведемо приклади відповідності:

Таблиця 4.2 - Рівні надійності роботи бази в залежності від масштабу

№ п/п	Рівень надійності, %	Приклад
1	99	База загального характеру
2	99,9	База інтернет-магазина/крупного порталу
3	99,99	Поштовий сервер великого підприємства
4	99,999	База банку / мобільного оператора

Основні поняття, які використовуються при розгляді надійності СУБД:

- Відмовостійкість - здатність до відновлення роботи додатків і даних після збою. Причиною відмови можуть служити апаратна несправність, проблеми програмного забезпечення, неправильні дії користувачів.

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

При проектуванні надійної системи необхідно розуміти причини відмови, від яких необхідно захиститися:

– фізичне руйнування ліній зв'язку;

– збій апаратної частини;

– позаштатна робота ПО;

– позаштатна робота персоналу;

– падіння під навантаженням.

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



7. Втрата зв'язку з сервером БД і / або фізича відмова сервера

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

Для створення надійної інфраструктури необхідно забезпечити як катастрофостійкість, так і відмовостійкість інфраструктури.

При використанні одного сервера катастрофостійкість зводиться до нуля, відмовостійкість також невисока.

Для забезпечення відмовостійкості єдиним вірним способом є підвищення надійності апаратної частини, поділ самої бази даних (сховище) і сервера СУБД.

Рисунок 15 - Класична схема з'єднання компонентів

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

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

Для забезпечення ж відмовостійкості інфраструктури необхідно комбінувати апаратні і програмні засоби. Розглянемо їх окремо.

Особливості використання апаратних засобів для забезпечення надійності СУБД:

– всі операції проводяться паралельно на однакових компонентах, а

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

– у разі виходу з ладу будь-якого компонента її «дублер» продовжує

роботу.

Особливості використання програмних способів для забезпечення надійності СУБД:

– одночасна робота декількох машин;

– дублювання даних і процесів;

– процедури автоматичного відновлення операційних систем, даних і додатків.

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

1. При будівництві звичайної по надійності СУБД можливе використання найменш витратного методу резервування даних - «холодного». Він вимагає періодичної зупинки сервера для створення з нього копії на резервну машину. При відмові сервера, починає працювати «холодний». Але цей метод не дає повне відновлення бази і вимагає часу (від декількох хвилин до декількох годин) для запуску сервера в якості основного.

Рисунок 16 - Приклад “холодного” резервування даних

2. При необхідності досягнення високої надійності системи доведеться звернутися до дещо більш дорогому рішенню, такому як «гаряче» резервування. Відміну від минулого рішення полягає в більш складній і довгій налаштуванні, більш дорогому обслуговуванні системи. Переваги даного рішення полягають у невпинному резервування сервера. Це дозволяє передавати дані з основного сервера на резервний постійно. У такому випадку сервер основний «відстає» від основного в середньому на одну транзакцію. У зв'язку з цим при відмові основного сервера резервна машина має повну (або з мінімальними втратами) базу і готова стати основним сервером протягом декількох десятків хвилин, необхідних на перенастроювання системи та запуск СУБД.

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

Рисунок 17 - Резервування з використанням проміжного ПЗ між додатком і базою

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

Рисунок 15 - Резервування з використанням реплікації декількох активних серверів

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

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

– Режим максимального захисту.

– Режим максимальної доступності.

– Режим максимальної продуктивності.

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

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

– RAID - для забезпечення відмово стійкості.

– Розподілені СЗД - для забезпечення катастрофостійкості.

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

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

Найбільш простим і дешевим варіантом є DAS / SAS. Він не гарантує постійний доступ до бази, так як в цьому випадку СГД безпосередньо з'єднується з сервером. Тому його використання рекомендується при побудові системи, що складається з одного сервера.

Рисунок 16 - Апаратне рішення для системи з однім сервером

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

Рисунок 4.6 - Доступ до сховища даних через мережу

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



Рисунок 17 - Побудова розподіленої системи без втрат швидкості передачі даних

Одним з варіантів підвищення рівня відмовостійкості є використання технології RAID ( англ. redundant array of independent disks - надлишковий масив незалежних дисків) - масив з декількох дисків (запам'ятовуючих пристроїв), керованих контролером, пов'язаних між собою швидкісними каналами передачі даних і сприймаються зовнішньою системою як єдине ціле. Залежно від типу використовуваного масиву може забезпечувати різні ступені відмовостійкості і швидкодії. Служить для підвищення надійності зберігання даних і / або для підвищення швидкості читання / запису.

Таблиця 4.3 - Рівні забезпечення відмовостійкості

Методи	Вартість (надмірність дисків, шт.)	Надійність (Кількість припустимих падінь), n - кількість дзеркал
RAID1	2n	n-1
RAID5	n+1	1
RAID6	n+2	2
RAID10	2n	n-1
RAID50	n+1	1

Таблиця 4.4 - Забезпечення стійкості при використанні різних методів

Методи	Простота розгортання	Простота використання	Консолідація ресурсів	Можливість масшта-бування	Вартість	Розподілена СЗД	Швид-кість передач даних	Надій-ність
SAN	-	+	+	+	Висока	+	+	Висока
NAS	+	+	+	+	Низька	+	-	Середня
DAS/ SAS	+	-	-	-	Низька	-	+	Низька

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

7.1 Позаштатна робота ПО і персоналу

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

Розглянемо способи відновлення бази при її пошкодженні:

– Відновлення з резервної копії бази

– Відновлення за журналом транзакцій

Будь-який з перерахованих вище способів вимагає певний час на реалізацію. Відновлення з резервної копії вимагає від декількох хвилин до декількох годин в залежності від розміру бази і не дозволяє відтворити рівно ту версію даних, яких була перед падінням сервера, частина даних втрачається. Для зменшення місця, необхідного для зберігання копії часто використовуються диференційовані і додаткові бекапи. Це дозволяє «знімати» з бази повну копію раз на тиждень / місяць, після чого резервувати тільки зміни з моменту останнього повного бекапа. Диференційоване резервування дозволяє відновити базу швидше, ніж додатковий, але вимагає більше місця для зберігання архіву. Як правило копія робиться раз на добу, при необхідності, раз на годину, так як сервер сильно перевантажується («гарячий» бекап) або стає недоступним для звернення користувачів («холодний» бекап) в момент резервування.

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

У розділі «Відмовостійкість» ми не будемо розглядати способи захисту від всіляких впливів людини на базу (SQL-ін'єкції, недобросовісний адміністратор та інші), це буде розглянуто в розділі «Безпека».

7.2 Падіння під навантаженням

Якщо відмова сервера викликаний занадто великим навантаженням, необхідно визначити причину такого навантаження і її постійність. Можна виділити три варіанти:

– DDoS-атаки

– Постійна перевантаження сервера через збільшення числа користувачів

– Періодична перевантаження сервера через пікових навантажень

Розвиток подій при першому варіанті ми розглянемо в розділі «Безпека».

При збільшенні навантаження на сервер існують різні варіанти вирішення проблем:

– Масштабування бази

– Оптимізація роботи СУБД

– Динамічне підключення серверів при піковому навантаженні

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

– MySQL

Для створення відмовостійкості та катастрофостійкості бази в MySQL використовується MySQL Cluster NDB. Важливими особливостями даної системи є робота з недорогими апаратними засобами і відсутність яких-небудь специфічних вимог до апаратних ресурсів або програмному забезпеченню.

MySQL Cluster NDB дозволяє організувати як «холодне», так і «гаряче» резервування. Також дана система реалізує асинхронні мульти-майстерні реплікації. Всі функції здійснюються на основі стандартних засобів MySQL через скрипти і зміну файлів конфігурацій, або через стороннє програмне забезпечення, таке як DRBD (наприклад, для створення мульти-майстерної реплікації).

До мінусів даної технології відносяться проблеми, які можуть виникнути при «гарячому» резервуванні в MySQL, а також відсутність можливості створення надійної синхронної мульти-майстерної реплікації. Це пов'язано з особливостями реалізації деяких функцій (наприклад, реалізація двуфазного завершення), використання яких, призводить до неузгодженості між серверами кластера. Подібні проблеми викликані тим, що MySQL Cluster NDB з'явився відносно недавно і, ймовірно, вони будуть вирішені в подальшому. Ще одним недоліком є ??складність і неочевидність реалізації всіх вищезгаданих методів.

– Oracle

Технологія реального додатків кластера дозволяє організувати розподілену відмовостійку систему будь-якого типу. Єдиним мінусом Oracle RAC є складність процесу налаштування кластера високої надійності.

– DB2

– MSSQL

7.3 Розрахунок середнього часу напрацювання до руйнування

Наведемо результати розрахунку середнього часу (в годинах) напрацювання до руйнування з втратою даних по виведеній автором формулою на прикладі дискових масивів RAID-0, 5,6 та 1 і при кількості дисків n = 2 ... 6.

Інтенсивність відмов диска для всіх таблиць л = 1/120000. Відповідно, середній час напрацювання до відмови диска становить 120000 годин.

Інтенсивність відновлення масиву в першій таблиці не враховується м = 0, а в решті таблицях м = 1/24, тобто в середньому 24 години на відновлення даних на 1 диск.

Максимальна кількість дисків які одночасно відновлюються в першій таблиці не враховується r = 0, а в інших або r = 1 (строго однодискові відновлення), або r = n (необмежені можливості щодо одночасного відновленню).

Додаткова інтенсивність помилок в першій таблиці не враховується е = 0, в інших таблицях або більше, або дорівнює, або менше інтенсивності відновлення.

Таблиця 4.5 - Система, що не відновлюється: r = 0, м=0, е = 0:

	n = 2	n = 3	n = 4	n = 5	n = 6
RAID-0 (s= 1)	60000	40000	30000	24000	20000
RAID-5 (s= 2)	-	100000	70000	54000	44000
RAID-6 (s= 3)	-	-	130000	94000	74000
RAID-1 (s= n)	180000	220000	250000	274000	294000

Таблиця 4.6 - Однодискове безпомилкове відновлення (без урахування додаткової інтенсивності помилок при відновленні): r = 1, м=1/24, е = 0:

	n = 2	n = 3	n = 4	n = 5	n = 6
RAID-0 (s= 1)	60000	40000	30000	24000	20000
RAID-5 (s= 2)	-	1,001*108	5,007*107	3,0054*107	2,0044*107
RAID-6 (s= 3)	-	-	1,2515*1011	5,008*1010	2,505*1010
RAID-1 (s= n)	3,0018*108	5,004*1011	6,25625*1014	6,25751*1017	5,21563*1020

Таблиця 4.7 - Багатодискове безпомилкове відновлення (без урахування додаткової інтенсивності помилок при відновленні):r = n, м=1/24, е = 0:

	n = 2	n = 3	n = 4	n = 5	n = 6
RAID-0 (s= 1)	60000	40000	30000	24000	20000
RAID-5 (s= 2)	-	1,001*108	5,007*107	3,0054*107	2,0044*107
RAID-6 (s= 3)	-	-	2,505*1011	1,0013*1011	5,008*1010
RAID-1 (s= n)	3,0018*108	1.0007*1012	3,75325*1015	1,50157*1019	6,25775*1022

Таблиця 4.8 - Однодискове відновлення з додатковою інтенсивністю помилок більшою, ніж інтенсивність відновлення: r = 1, м=1/24, е = 9/24:

	n = 2	n = 3	n = 4	n = 5	n = 6
RAID-0 (s= 1)	60000	40000	30000	24000	20000
RAID-5 (s= 2)	-	42223	31111	24667	20444
RAID-6 (s= 3)	-	-	31175	34692	20457
RAID-1 (s= n)	66669	42473	31184	24698	20463

Таблиця 4.9 - Багатодискове відновлення з додатковою інтенсивністю помилок більшою, ніж інтенсивність відновлення: r = n, м=1/24, е = 9/24:

	n = 2	n = 3	n = 4	n = 5	n = 6
RAID-0 (s= 1)	60000	40000	30000	24000	20000
RAID-5 (s= 2)	-	42223	31111	24667	20444
RAID-6 (s= 3)	-	-	31236	24717	20470
RAID-1 (s= n)	66669	427200	31281	24734	20480

Таблиця 4.10 - Однодискове відновлення з додатковою інтенсивністю помилок рівною інтенсивності відновлення: r = 1, м=1/24, е = 1/24:

	n = 2	n = 3	n = 4	n = 5	n = 6
RAID-0 (s= 1)	60000	40000	30000	24000	20000
RAID-5 (s= 2)	-	600007	40005	30004	24003
RAID-6 (s= 3)	-	-	45019	32013	25010
RAID-1 (s= n)	120011	80035	50056	34070	25745

Таблиця 4.11 - Багатодискове відновлення з додатковою інтенсивністю помилок рівною інтенсивності відновлення: r = n, м=1/24, е = 1/24:

	n = 2	n = 3	n = 4	n = 5	n = 6
RAID-0 (s= 1)	60000	40000	30000	24000	20000
RAID-5 (s= 2)	-	60007	40005	30004	24003
RAID-6 (s= 3)	-	-	50021	34015	26011
RAID-1 (s= n)	120011	100039	80087	64166	52296

Таблиця 4.12 - Однодискове відновлення з додатковою інтенсивністю помилок меншою, ніж інтенсивність відновлення: r = 1, м=1/24, е = 1/216:

	n = 2	n = 3	n = 4	n = 5	n = 6
RAID-0 (s= 1)	60000	40000	30000	24000	20000
RAID-5 (s= 2)	-	219784	119910	77956	55978
RAID-6 (s= 3)	-	-	523886	239608	136838
RAID-1 (s= n)	599245	1835152	41533358	7490412	11242880

Таблиця 4.13 - Багатодискове відновлення з додатковою інтенсивністю помилок меншою, ніж інтенсивність відновлення: r = n, м=1/24, е = 1/216:

	n = 2	n = 3	n = 4	n = 5	n = 6
RAID-0 (s= 1)	60000	40000	30000	24000	20000
RAID-5 (s= 2)	-	219784	119910	77956	55978
RAID-6 (s= 3)	-	-	927755	401188	217644
RAID-1 (s= n)	599245	3450304	22700604	161287651	1200034082

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

– RAID-0 за визначенням не може розглядатися в якості методу

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

– RAID-5 є найдешевшим компромісом між відмовостійкістю і

надмірністю і володіє напрацюванням більшим напрацювання окремого диска тільки при n = 3 дисках, при n> 3 напрацювання масиву поступається напрацюванню окремого диска. Такий масив може використовуватися в системах резервного копіювання.

– RAID-6 є відносно непоганим компромісом між відмовостійкістю і

– надмірністю і володіє напрацюванням більшим напрацювання окремого диска

– при кількості дисків аж до n = 6 (при n ? 7 поступається окремому диску). Такий масив може використовуватися в системах зберігання даних, для яких періодично виконується резервне копіювання.

– RAID-1 є найдорожчим компромісом між відмовостійкістю і надмірністю і володіє напрацюванням істотно більшим напрацювання окремого диска для будь-якого числа дисків, більш того, із зростанням числа дисків напрацювання також значно збільшується. В силу самої високої

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



8. Оцінка загального об'єму архіву

Оцінка загального об'єму архіву використовується з метою виявлення мінімального зберігання архівної інформації с потребуємими параметрами зберігання.

Размещено на http://www.allbest.ru/

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

На рис.1 показано лінійну залежність, коли приріст постійний , а на рис.2 приріст пропорційний початковому об'єму інформації.



8.1 Вибір коефіцієнта для оцінки об'єму внутрішніх накопичувачів

Размещено на http://www.allbest.ru/

Під «електроною документацією» розуміють офісні докуенти та тексти ПО, схеми та інші документи крім файлів, представлених в графічних форматах.

Під категорією «інформація в спеціалізованих форматах» підрозумівають, наприикла лікарскі дані в форматі DICOM.

У випадку коли потреби необговорені типи хмарних даних коефіціенти повині включаати, 10%-20% запасу (коефіціент береться в рамках 0,1:0,2).

Таблиця. Величини коефіціенту для різних організацій

Категорія	k\0	Н\0	k\В	Н\В
Електронна документація	0,4:0,6	0,5:0,6	0,4:0,6	0,3:0,5
Електронна почта	0,5\0,7	0,5\0,6	0,4\0,6	0,3\0,5
Фото,аудіо та відео матеріали	0,4\0,5	0,3\0,5	0,4\0,5	0,2\0,4
Бази даних Програмне забезпечення	0,5\0,6	0,4\0,5	0,3\0,4	0,2\0,3
Архів	0,3\0,4	0,3\0,4	0,2\0,4	0,2\0,3
Інформація в спеціалізованих форматах	05,\0,7	0,6\0,7	0,3\0,4	0,2\0,3

Таблиця.Величини коефіціентів для різних організацій k,kt,kr

Розрахунок ООА- використовується для зберігання внутрішньої інформації організації.

Наприклад: розрахувати об'єм 6 АЕ до 10 робочих днів і частотою копіювання до 2-х разів на добу. Оцінка ПО показала величину 753Гб.таб.3.

Таблиця 3

Основними задачами ООА являється:

1.Спроектувати систему зберігання,щоб вона відповідала даним вимогам;

2.Зменшити фінансові затрати на оновлення системи зберігання;

3. Збільшити точність планових затрат на потребує мий період часу;

4.Звільнити частину робочого часу адміністратора для виконання інших задач.



Висновки та рекомендації

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

При виконанні роботи розраховані параметри модулів пожежогасіння для сайтів базових станцій, параметри архіву систем відеоспостереження, відстань спостереження при формування операторського центру системи СОТ.

Результати роботи можуть бути впроваджені на прикладі мереж операторів, від локальних до глобальних.



Перелік посилань

http://www.hwp.ru/articles/Sovremennie_metodi_rezervirovaniya_dannih_serverov_i_rabochih_stantsiy_70045/?PAGEN_1=4

http://osspractice.org/?page_id=130

1. Скляров Д. В. Искусство защиты и взлома информации. - СПб.: БВХ-Петербург. 2004.288 с.

2. Багаев М. А., Дубровин А. С., Застрожнов И. И., Макаров О. Ю., Рогозин Е. А., Сумин В. И. Методы и средства автоматизированной оценки и анализа качества функционирования программных систем защиты информации: Монография. - Воронеж: ВорГТУ, 2004. 181 с.

3. Вольфганг Ш. Комбинирование помогает // Журнал сетевых решений LAN. 2005, № 11, с. 78- 80.

Размещено на Allbest.ru

...