Page 86 - 4636
P. 86
4 БЕЗПЕКА ВЕБ-ДОДАТКІВ
4.1 Стратегії захисту
Одне з найбільш чудових властивостей Інтернету - відкритість та доступність для всіх - може
виявитися серйозним головним болем, з яким доведеться зіткнутися вам, як автору веб-додатка. У
мережі існує безліч компютерів, та не всі користувачі мають благородні наміри. За наявності такої
небезпеки просто страшно думати про беззахистний веб-додаток, який може працювати з
конфіденційною інформацією на зразок номерів кредитних карток, інформації про банківські рахунки
або історію хвороби. Але підприємство має працювати, і ми - його автори - повинні подбати не тільки
про простий захист комерційних аспектів програми, але і розробити підхід до планування та
забезпечення безпеки. Головне тут - знайти належний баланс між необхідністю захисту та
необхідністю мати робочий додаток. Відразу налаштуйтеся на правильний лад. Безпека - це не просто
один з аспектів. Якщо ви зібралися написати веб-додаток і складаєте список його бажаних
властивостей, то безпека - не пункт, який можна включити в цей список і виділити на роботу над ним
пару днів. Вона повинна пронизувати весь додаток, і зусилля на її підтримку ніколи не повинні
припинятися, навіть після завершення розробки і розгортання додатку. Постійно враховуючи і
плануючи з самого початку різні способи атак на систему з метою її компрометації, можна створити
код, який знизить ймовірність виникнення подібних проблем. Крім того, це заощадить вам сили і час,
які ви б витратили на нагальну підгонку всіх частин додатка в кінці розробки, коли руки нарешті
дійдуть і до безпеки (і коли майже напевно будуть упущені з уваги багато можливих неприємностей).
Баланс між безпекою і зручністю використання
Один з головних питань, яке доводиться вирішувати при проектуванні системи - паролі.
Користувачі часто вибирають паролі, які неважко розгадати за допомогою спеціального ПЗ, особливо
якщо використовуються слова, наявні у словниках. Хотілося б знайти спосіб зниження ймовірності
розкриття користувальницького пароля і подальшої компрометації системи. Одне з рішень - вимагати,
щоб кожен користувач пройшов через серію чотирьох вхідних діалогів, і кожен раз з окремим
паролем. Можна також вимагати, щоб користувач міняв ці паролі не рідше одного разу в місяць, щоб
нові паролі ніколи не співпадали зі старими. Це підвищило б безпеку системи, і зломщикам
знадобилося б набагато більше часу на злом процесу входу і компрометацію системи. На жаль, така
система буде настільки захищеною, що ніхто не захоче нею користуватися - на якомусь рівні
складності користувачі просто вирішать, що краще не зв'язуватися з подібною морокою. Так що
важливо турбуватися не тільки про безпеку, але і про її вплив на зручність роботи. Легка у
використанні система з невисоким рівнем захисту може більше сподобатися користувачам, але
підвищить ймовірність виникнення проблем з безпекою і, як наслідок, з перебоями в роботі
підприємства. З іншого боку, система з найпотужнішим захистом, яка в силу цього є абсолютно
незручною у роботі, просто відлякує користувачів і також негативно вплине на справи. Нам, як
проектувальникам програм, потрібні способи підвищення безпеки без пропорційного погіршення
зручності роботи з системою. Як і у всіх питаннях, пов'язаних з призначеним для користувача
інтерфейсом, тут немає чітких і однозначних правил, так що доведеться покладатися на власні оцінки,
тестування зручності роботи і цільові групи, щоб дізнатися, як користувачі будуть реагувати на наші
прототипи та проектні рішення.
Моніторинг безпеки. Коли веб-додаток буде повністю розроблено та розгорнуто на громадських
серверах для роботи з реальними людьми, наша робота все ще не буде завершена. У поняття захисту
входить спостереження за роботою системи, перегляд журналів та інших файлів, щоб оцінити
продуктивність і використання системи. Тільки уважне спостереження за роботою системи (можливо,
з допомогою спеціальних засобів, які виконують за нас частину цього спостереження) дозволяє
зрозуміти, чи існують проблеми з безпекою, і виявити області, які вимагають розробки додаткового
83