документація<Попередній | зміст | Наступна>
7.1. Визначення політики безпеки
Обговорювати безпеку в широких межах недоцільно, оскільки ця ідея являє собою широкий спектр концепцій, інструментів і процедур, жодна з яких не застосовується універсально. Вибір серед них вимагає точного уявлення про ваші цілі. Захист системи починається з відповіді на кілька запитань. Поспішаючи впровадити довільний набір інструментів, ви ризикуєте зосередитися на неправильних аспектах безпеки.
Зазвичай краще визначити конкретну мету. Хороший підхід, щоб допомогти з цим визначенням, починається з таких питань:
• Що ти намагаєшся захистити? Політика безпеки буде різною залежно від того, чи хочете ви захистити комп’ютери чи дані. В останньому випадку також потрібно знати, які дані.
• Що ви намагаєтеся захистити проти? Це витік конфіденційних даних? Випадкова втрата даних? Втрата доходу, спричинена порушенням обслуговування?
• Крім того, хто ти намагаєшся захиститися від? Заходи безпеки будуть зовсім різними для захисту від опечатки звичайним користувачем системи та захисту від визначеної зовнішньої групи зловмисників.
Термін «ризик» зазвичай використовується для спільного позначення цих трьох факторів: що захищати, що слід запобігти та хто може це зробити. Моделювання ризику вимагає відповідей на ці три запитання. На основі цієї моделі ризику можна сконструювати політику безпеки та реалізувати її за допомогою конкретних дій.
Постійне опитування Брюс Шнайєр, світовий експерт з питань безпеки (не тільки комп’ютерної безпеки), намагається протистояти одному з найважливіших міфів безпеки з гаслом: «Безпека — це процес, а не продукт». Активи, які підлягають захисту, змінюються з часом, а також загрози та засоби, доступні потенційним зловмисникам. Навіть якщо спочатку політика безпеки була ідеально розроблена та реалізована, ви ніколи не повинні спочивати на досягнутому. Компоненти ризику еволюціонують, і відповідь на цей ризик має розвиватися відповідно.
Постійне опитування Брюс Шнайєр, світовий експерт з питань безпеки (не тільки комп’ютерної безпеки), намагається протистояти одному з найважливіших міфів безпеки з гаслом: «Безпека — це процес, а не продукт». Активи, які підлягають захисту, змінюються з часом, а також загрози та засоби, доступні потенційним зловмисникам. Навіть якщо спочатку політика безпеки була ідеально розроблена та реалізована, ви ніколи не повинні спочивати на досягнутому. Компоненти ризику еволюціонують, і відповідь на цей ризик має розвиватися відповідно.
Додаткові обмеження також варто враховувати, оскільки вони можуть обмежити діапазон доступних політик. Як далеко ви готові зайти, щоб захистити систему? Це питання має великий вплив на те, яку політику слід проводити. Дуже часто відповідь визначається лише з точки зору грошових витрат,
але слід також враховувати й інші елементи, наприклад, кількість незручностей, завданих користувачам системи, або зниження продуктивності.
Після моделювання ризику ви можете почати думати про розробку фактичної політики безпеки.
Існують крайнощі, які можуть зіткнутися з рішенням щодо рівня захисту безпеки. З одного боку, забезпечити базову безпеку системи може бути надзвичайно просто.
Наприклад, якщо система, яку потрібно захищати, містить лише вживаний комп’ютер, єдине використання якого полягає в тому, щоб додати кілька чисел в кінці дня, рішення не робити нічого особливого для його захисту було б цілком розумним. Внутрішня цінність системи низька, а цінність даних дорівнює нулю, оскільки вони не зберігаються на комп’ютері. Потенційний зловмисник, який проникне в цю систему, отримає лише калькулятор. Вартість захисту такої системи, ймовірно, буде більшою, ніж вартість порушення.
На іншому кінці спектру, ви можете захотіти захистити конфіденційність секретних даних якнайповніше, випереджаючи будь-які інші міркування. У цьому випадку прийнятною відповіддю було б повне знищення даних (безпечне стирання файлів, подрібнення жорстких дисків на біти, потім розчинення цих бітів у кислоті тощо). Якщо є додаткова вимога, що дані повинні зберігатися для майбутнього використання (хоча це не обов’язково є легкодоступними), і якщо вартість все ще не є фактором, то відправною точкою буде зберігання даних про сплав іридію та платини. пластини, що зберігаються в бомбозахищених бункерах під різними горами світу, кожна з яких (звичайно) повністю таємна й охороняється цілими арміями.
Незважаючи на те, що ці приклади можуть здатися екстремальними, вони, тим не менш, будуть адекватною відповіддю на певні визначені ризики, оскільки вони є результатом процесу мислення, який враховує цілі, яких необхідно досягти, та обмеження, які необхідно досягти. Виходячи з обґрунтованого рішення, жодна політика безпеки не є більш чи менш поважною, ніж будь-яка інша.
Повертаючись до більш типового випадку, інформаційну систему можна сегментувати на послідовні і переважно незалежні підсистеми. Кожна підсистема матиме власні вимоги та обмеження, тому оцінку ризику та розробку політики безпеки слід проводити окремо для кожної підсистеми. Варто пам’ятати про те, що невелику поверхню атаки легше захистити, ніж велику. Організація мережі також повинна бути розроблена відповідним чином: чутливі служби повинні бути зосереджені на невеликій кількості машин, і ці машини повинні бути доступні лише через мінімальну кількість маршрутів або контрольних пунктів. Логіка проста: легше захистити ці контрольні точки, ніж захистити всі чутливі машини від усього зовнішнього світу. Саме в цей момент стає очевидною корисність фільтрації мережі (у тому числі за допомогою брандмауерів). Цю фільтрацію можна реалізувати за допомогою спеціального обладнання, але більш простим і гнучким рішенням є використання програмного брандмауера, такого як інтегрований в ядро Linux.