Ризики та заходи, пов'язані з використанням бібліотек при побудові бізнес-систем

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

Що таке бібліотека

При створенні бізнес-систем, компанії-розробники рідко створюють всі необхідні програми самостійно. Замість цього, вони зазвичай створюють основу за допомогою “готових компонентів програмного забезпечення” і доповнюють її власними розробками. Ці “готові компоненти програмного забезпечення” називаються “бібліотеками”. Загальноприйнято використовувати бібліотеки для розробки універсальних функцій. Універсальні функції – це такі, як “функція входу в систему” або “функція отримання даних з бази даних”, які є високим попитом у будь-якій галузі та в будь-якій країні. Для таких високопопулярних функцій існують відповідні бібліотеки. З іншого боку, для функцій, які не є універсальними, наприклад, для задоволення унікальних вимог клієнта, готові бібліотеки не існують, тому компанія-розробник має створювати їх самостійно.

Також варто зазначити, що є слово “фреймворк”, яке має схоже значення з “бібліотекою”. Існує також термін OSS (Open Source Software – відкрите програмне забезпечення). В контексті бізнес-систем, OSS – це компоненти системи, які є тим самим, що і “бібліотеки” в цій статті, але це слово може бути більш знайомим. Однак, в цій статті ми будемо використовувати термін “бібліотека”.

Переваги бібліотеки: швидкість та безпека

Існують дві причини, чому IT-компанії віддають перевагу використанню бібліотек над розробкою власних рішень.

• Швидкість розробки вища, ніж при самостійній розробці
• Безпека вища, ніж при самостійній розробці

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

Недоліки використання бібліотек

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

Якщо не оновлювати, виникає вразливість

Злочинці, які прагнуть вкрасти особисті дані, інформацію про кредитні картки або комерційні таємниці, щодня шукають вади в безпеці бібліотек (та іншого програмного забезпечення). Ці вади в IT-термінології називаються “вразливостями”. Існує багато випадків, коли було використано вразливості в бібліотеках, що призвело до збитків. Наприклад, було атаковано вразливість бібліотеки Struts2, яку використовували на сайті опитувань Міністерства землі, інфраструктури, транспорту та туризму Японії (Japanese Ministry of Land, Infrastructure, Transport and Tourism), в результаті чого було викрадено близько 200 тисяч записів клієнтів. Також відомий випадок, коли сайт продажу квитків, який використовував Struts2, міг втратити інформацію про 32 187 кредитних карт. Вразливості бібліотек, які були невідомі на момент поставки системи, можуть виявитися пізніше.

Оновлення супроводжується ризиком зупинки системи

На практиці бувають випадки, коли неможливо оновити бібліотеку, незважаючи на наявність вразливостей. Це пов’язано з ризиком тимчасового припинення роботи системи під час оновлення. Бібліотеки не є програмами, написаними компаніями-розробниками систем, тому повністю зрозуміти їх вміст у реальних умовах важко. Тому ризик виникнення непередбачених помилок в системі під час оновлення та тимчасового припинення її роботи не може бути повністю виключений. Клієнти можуть відчувати обурення, якщо компанія-розробник системи не розуміє вмісту поставленої системи. Однак факт полягає в тому, що бібліотеки, які використовуються в сучасних системах, за якістю та кількістю перевищують те, що може впоратися звичайна компанія-розробник систем. Наприклад, є бібліотека “React”, яка є надзвичайно популярною серед бібліотек для створення користувацьких інтерфейсів. Ця бібліотека є дуже високоякісною, оскільки її створили інженери Facebook, а за обсягом вона містить 195 486 рядків коду (примітка 1).

Випадки, коли вразливості стали предметом судового розгляду

Існує питання про те, хто несе відповідальність, коли виникає шкода через вразливості, що походять від бібліотеки. В якості довідки можна використати рішення Токійського окружного суду від 23 січня 2014 року (Heisei 26). Позивач доручив системній компанії-відповідачу розробити систему продажу. Однак після запуску системи, через її вразливості, була викрадена інформація про кредитні картки кінцевих користувачів, і позивач зазнав збитків на суму близько 32 мільйонів єн через вибачення та розслідування. У договорі, який уклали позивач та відповідач, була домовленість про відшкодування, що обмежує суму відшкодування до суми договору у випадку, якщо збиток виник через недбалість відповідача. Спір стосувався того, чи можна застосувати цю домовленість про відшкодування. Рішення суду полягало в тому, що відповідач мав серйозну недбалість, і відповідачу було наказано відшкодувати збитки, що перевищують суму договору, оскільки домовленість про відшкодування не може бути застосована, якщо є серйозна недбалість.

Відповідач, як компанія, що займається плануванням систем обробки інформації, створенням веб-сайтів, розробкою бізнес-систем тощо, розгорнула бізнес, використовуючи свої професійні знання про програмування, і надала цю веб-додаток як частину свого бізнесу. Можна вважати, що позивач довіряв цим професійним знанням і уклав цей договір про замовлення системи. Відповідач мав високий рівень обов’язку бути обережним, оскільки, як було зазначено вище, якщо не було заходів проти SQL-ін’єкцій, третя особа могла б провести атаку SQL-ін’єкції, і особиста інформація могла б витікати з цієї бази даних. Відповідач міг передбачити це, і, враховуючи те, що Міністерство економіки, торгівлі та промисловості та IPA вказали на атаку SQL-ін’єкції як на типовий метод атаки на веб-додатки, і вони попереджали про це, було легко передбачити, що така ситуація могла виникнути. Крім того, використання механізму зв’язування або процесу екранування могло б уникнути цього витоку, і не було доказів, що великі зусилля або витрати були потрібні для виконання цих технічних заходів для уникнення витоку. Таким чином, відповідач мав серйозну недбалість.

Рішення Токійського окружного суду від 23 січня 2014 року

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

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

Питання та відповіді про правові проблеми використання OSS в епоху IoT [PDF][ja] (стор. 84)

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

Що є більш реалістичним заходом проти вразливостей?

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

1. Укладання договору про обслуговування, включаючи оновлення бібліотеки
2. Діагностика вразливостей

Укладання договору про обслуговування, включаючи оновлення бібліотеки

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

Діагностика вразливостей

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

Діагностика вразливостей варіюється від безкоштовних інструментів до дорогих ручних перевірок. Особливо важливо звернутися до спеціалістів у діагностиці вразливостей та витратити достатньо коштів на заходи проти вразливостей, якщо ви працюєте з інформацією, витік якої може бути критичним. Крім того, вразливості виявляються щодня, тому важливо проводити діагностику вразливостей[ja] (P15) не тільки під час доставки, але і після доставки на постійній основі.

Підсумки

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