У цій частині ми розглянемо. Ризики надто поверхового моделювання. Який вигляд має глибоке моделювання. Дефекти безпеки у вигляді порушеної бізнес-цілісності. Зменшення ризиків з допомогою глибокого моделювання. У сучасному цифровому світі, де безпека даних та інформаційних систем є вельми важливою, виникає реальна загроза поверхневого моделювання. Ризики цього підходу можуть призвести до дефективної безпеки, порушення бізнес-цілісності та інших серйозних наслідків. Один із способів зменшення цих ризиків – використання глибокого моделювання. Поверхневе моделювання та його Ризики: Поверхневе моделювання означає створення спрощених моделей без глибокого аналізу та розуміння процесів. Це може призвести до неповної інформації про можливі загрози та уразливості.
Результатом може бути недостатній рівень безпеки та порушення цілісності інформаційних систем. Глибоке Моделювання та Його Переваги: Глибоке моделювання передбачає детальний аналіз, урахування всіх можливих варіантів та реальних ризиків. Це дозволяє виявити потенційні проблеми, включаючи дефекти безпеки, порушення цілісності та можливість несанкціонованого доступу. Дефекти Безпеки та Порушена Бізнес-Цілісність: Дефекти безпеки можуть призвести до порушення цілісності даних та інформаційних систем. Це може включати несанкціонований доступ, втрату даних та пошкодження репутації. Порушена бізнес-цілісність може призвести до великих фінансових втрат та втрати довіри з боку клієнтів. Зменшення Ризиків з Допомогою Глибокого Моделювання: Глибоке моделювання дозволяє ідентифікувати потенційні ризики та враховувати їх на всіх етапах проектування та розробки. Це включає в себе аналіз можливих загроз, встановлення захисних механізмів та постійний моніторинг. Ризики поверхового моделювання можуть вплинути на безпеку інформаційних систем та бізнес-цілісність. Використання глибокого моделювання дозволяє виявляти, попереджувати та зменшувати ризики шляхом детального аналізу та ефективного захисту.
Це правдива історія про те, як негативні цифри можуть призвести до великих фінансових втрат. Він заснований на проблемі, яка була у нашого клієнта, над якою ми працювали, але для того, щоб поділитися з вами деталями, нам довелося спотворити контекст. Зокрема, ми змінили продукт, який продавала компанія: запевняємо, це були не книги. Цікаво, що є подібні приклади, в яких книги насправді фігурували. Amazon зіткнувся з подібною помилкою програмного забезпечення про 2000. Однак ми не знаємо тонкощів цих справ.
Це також історія про те, як серйозна проблема безпеки існує в промислових умовах протягом тривалого часу, не привертаючи уваги і не викликаючи жодних несправностей – принаймні не в технічному сенсі. Проте через неї компанія втратила гроші. На практиці компенсувати втрати було неможливо, але вдалося розкрити особи тих, хто нажився на цій проблемі.
Нарешті, ця історія про те, як міжнародна торгова компанія випадково дозволила своїм клієнтам самостійно отримувати знижки в своєму інтернет-магазині. Ми покажемо, як його фінансові втрати стали наслідком поверхневого дизайну з недостатнім або відсутнім моделюванням, з яким ми часто стикаємося. Ми також проілюструємо важливість чіткого та усвідомленого моделювання.
У цьому інтернет-магазині немає нічого особливого – типовий сайт, де клієнт кладе книги в кошик, оформляє замовлення, здійснює оплату банківською картою і потім отримує товар через службу доставки (рис. 2.1).
Магазин відкрився давно і продовжує розвиватися. Компанія запросила команду фахівців з безпеки для проведення аудитів і тестування. Зокрема, перевіряють конфігурацію системи у виробничому середовищі та її кодову базу. А також виконувати тести, намагаючись маніпулювати системою ззовні в пошуках дірок в безпеці. Команді було доручено розслідувати все, що може здатися підозрілим.
Аналіз показав, що інфраструктура досить надійна. Слідом за цим фахівці взялися за брандмауери і сканували відкриті порти операційної системи. Вони відправляли шкідливі пакети на веб-сервер, але це не викликало ніяких проблем. І це не дивно: в наші дні проблеми з безпекою рідко виникають через дефекти інфраструктури. Всі вже знають, що об’єкти, які не повинні бути доступні всім, потрібно ізолювати.
У той же час інші члени команди досліджували додаток інтернет-магазину з технічної точки зору, намагаючись знайти способи обійти механізм аутентифікації. Перевіряли, чи можна вкрасти відкритий сеанс клієнта, намагалися «отруїти» куку. І знову безрезультатно. Але і тут все було очікувано, так як безпека досягалася правильною настройкою веб-сервера, а творці магазину чітко перевіряли документацію при налаштуванні свого додатка.
Прорив стався, коли один з членів команди, Джо Тестер, зацікавився полем «Кількість», в якому замовник вказує, скільки книг йому потрібно на формі замовлення. Він вказав у ньому фрагмент коду JavaScript, щоб перевірити, чи буде він виконаний. Але нічого не сталося. Потім він спробував спровокувати SQL-ін’єкцію, знову безуспішно. Нарешті, з цікавості він ввів -1 як кількість примірників «Гамлета» за ціною 39 доларів. Тобто Джо Тестер намагався купити один негативний «Гамлет» – анти-«Гамлет».
На свій подив, він не отримав повідомлення про помилку. Магазин прийняв замовлення і виконав процедуру його обробки. Джо надав кредитну картку і отримав електронний лист із підтвердженням того, що замовлення прийнято. “Дивно”,—подумав він. Зробивши запис у своєму блокноті, Джо продовжив свою роботу. Наступного ранку у двері кабінету служби безпеки постукали, і жінка невпевнено заглянула всередину.
“Я з бухгалтерії”, – представилася вона. «Я хотів запитати, чи знаєте ви когось на ім’я Джо Тестер?» і відразу уточнив: «Я просто запитав тут, і хтось сказав мені, що ви можете знати».
«Так, це наш тестовий клієнт», – відповіла команда. “Що з ним?”
Бухгалтерка продовжила: «Я переглядала журнал дебіторської заборгованості і помітила, що система створила для цього клієнта рахунок-фактуру на повернення 39 доларів США. Але коли ми вже збиралися відправити поштою його книгу, з’ясувалася дивна річ: його адреса збігається з адресою цього офісу.
Ось чому я насторожився і почав запитувати».
Система намагалася заплатити гроші Джо Тестеру. Недобре.
Давайте зробимо крок назад і подивимося, що вийшло. Інтернет-магазин прийняв замовлення з -1 копією Гамлета, і це, безсумнівно, дивно. Але давайте подумаємо про логічні наслідки, які це тягне за собою.
Якщо хтось купує книгу за ціною 39 доларів, сума замовлення становитиме 39 доларів, тому логічно, що клієнт платить цю суму магазину. У нашому випадку Джо Тестер купив не копію «Гамлета», а негативну, тому сума замовлення становить -39 доларів (рис. 2.2). Він повинен заплатити магазину 39 доларів, або магазин повинен заплатити йому 39 доларів. Але магазин не повинен платити гроші таким чином. Можливо, саме Джо Тестер повинен подарувати магазину копію «Гамлета».
З точки зору безпеки це порушення. Один з аспектів безпеки стосується цілісності даних: це означає, що дані не повинні бути змінені або згенеровані несанкціонованим способом. Найчастіше цілісність розглядається в технічному контексті: надання контрольних сум і криптографічних підписів для забезпечення того, щоб дані змінювалися відповідно до правил. У нашому випадку мова йде не про технічні, а про правила ведення бізнесу. Надсилайте гроші клієнтам за антикниги — Не найкраща бізнес-модель. Ми маємо справу з порушенням ділової доброчесності.
Попереджена, команда безпеки розпочала розслідування, щоб зрозуміти, що насправді відбувається. Виходить, що система інтернет-магазину розраховує суму «До оплати» в розмірі -39 доларів за замовлення, що логічно, хоч і дивно. Ця кількість послідовно проходить через кілька інших систем (рис. 2.3).
Найцікавіше в цій історії те, що проблему безпеки неможливо зрозуміти без розуміння кожної з задіяних в ній систем, їх взаємодії і реакції на зовнішні фактори. Почнемо з двох: білінгової системи і журналу дебіторської заборгованості.
Білінгова система призначена для збору платежів клієнтів. Якщо клієнт вважає за краще платити кредитною карткою і робить замовлення на $347, ця сума стягується з його кредитної картки. Але клієнт може вибрати інші способи оплати: рахунок-фактуру, ощадний рахунок або подарункові картки. Деякі клієнти мають різні способи оплати на різні суми. Великі замовлення можна оплачувати безпосередньо, а невеликі замовлення накопичуватися на рахунку-фактурі, який виставляється в кінці місяця.
Джо Тестер робить замовлення на -39 доларів, і ця сума перераховується в білінгову систему. У ньому є модуль для роботи з кредитками, який не знає, що робити з негативними сумами. З точки зору виставлення рахунків, негативна сума означає, що вам не потрібно нічого приймати до оплати. Процедура оплати пропускається.
Тепер перейдемо до журналу дебіторської заборгованості. Цей журнал є частиною системи бухгалтерського обліку і містить записи клієнтів, які винні компанії гроші, заборгованість існує в період між покупкою книги і надходженням оплати на рахунок компанії. Журнал дебіторської заборгованості має баланс кожного клієнта. Наприклад, якщо хтось розміщує замовлення на 347 доларів США та вирішує оплатити рахунок-фактуру, на баланс клієнта додається 347 доларів США. Пізніше, Коли компанія отримує платіж, баланс в журналі обнуляється. Іноді люди переплачують — наприклад, ми могли б заплатити 350 доларів. В цьому випадку баланс стає негативним, -3 долари, що означає: компанія винна гроші клієнту. З точки зору банку, заборгованість компанії перед клієнтом цілком нормальна навіть в довгостроковій перспективі. Але для книжкового інтернет-магазину це допустимо лише як тимчасова ситуація. Якщо це сталося, магазин повинен постаратися якомога швидше погасити заборгованість.
У звичайній ситуації, щоб виплатити борг клієнту, книжковий інтернет-магазин відправляє зворотний рахунок-фактуру. Ці рахунки обробляються групами – ось що мала на увазі бухгалтер, коли сказала: «Я подивилася журнал дебіторської заборгованості …» Коли Джо Тестер зробив своє антизамовлення, система інтернет-магазину відправила платіж у розмірі -$39 в журнал дебіторської заборгованості, що відразу створило борг компанії перед Джо. Наступної ночі система обробляє журнал, знаходить неоплачений борг і створює зворотний рахунок-фактуру, який потрібно відправити Джо, щоб обнулити його баланс в журналі. Це фактично означає, що наш тестовий клієнт отримує оплату (рисунок 2.4). Це рахунок-фактура, що прониклива бухгалтерка вважала підозрілою і через яку у неї виникали питання.
Перевірки проводилися в реальних умовах, тому очевидно, що виявлений розрив існував в системі вже деякий час. Цей конкретний випадок був виявлений тільки через підозрілу адресу. Але подібні випадки могли статися і раніше.
Було розпочато фінансове розслідування, щоб визначити, наскільки серйозною була проблема. Оперативна група та команди безпеки об’єднали зусилля, щоб перехресно перевірити всі створені рахунки-фактури на повернення. Після відсіювання рахунків-фактур для постачальників і партнерів залишилися тільки записи клієнтів. Більшість з них були правильними і пояснювалися пошкодженням товару або іншими зрозумілими причинами. Залишилася невелика частина, тому проблема була не надто серйозною – по крайней мере, так здавалося в той момент. Проте сам факт того, що безоплатна відправка грошей залишилася непоміченою, був дивним. Технічне розслідування продовжувало розкривати всі подробиці того, що відбувалося при замовленні антикнижки. Виявилося, що в цьому процесі задіяні ще дві важливі системи: складська і диспетчерська.
Найцікавіше в цій історії те, що проблему безпеки неможливо зрозуміти без розуміння кожної з задіяних в ній систем, їх взаємодії і реакції на зовнішні фактори. Почнемо з двох: білінгової системи і журналу дебіторської заборгованості.
Білінгова система призначена для збору платежів клієнтів. Якщо клієнт вважає за краще платити кредитною карткою і робить замовлення на $347, ця сума стягується з його кредитної картки. Але клієнт може вибрати інші способи оплати: рахунок-фактуру, ощадний рахунок або подарункові картки. Деякі клієнти мають різні способи оплати на різні суми. Великі замовлення можна оплачувати безпосередньо, а невеликі замовлення накопичуватися на рахунку-фактурі, який виставляється в кінці місяця.
Джо Тестер робить замовлення на -39 доларів, і ця сума перераховується в білінгову систему. У ньому є модуль для роботи з кредитками, який не знає, що робити з негативними сумами. З точки зору виставлення рахунків, негативна сума означає, що вам не потрібно нічого приймати до оплати. Процедура оплати пропускається.
Тепер перейдемо до журналу дебіторської заборгованості. Цей журнал є частиною системи бухгалтерського обліку і містить записи клієнтів, які винні компанії гроші, заборгованість існує в період між покупкою книги і надходженням оплати на рахунок компанії. Журнал дебіторської заборгованості має баланс кожного клієнта. Наприклад, якщо хтось розміщує замовлення на 347 доларів США та вирішує оплатити рахунок-фактуру, на баланс клієнта додається 347 доларів США. Пізніше, Коли компанія отримує платіж, баланс в журналі обнуляється. Іноді люди переплачують — наприклад, ми могли б заплатити 350 доларів. В цьому випадку баланс стає негативним, -3 долари, що означає: компанія винна гроші клієнту. З точки зору банку, заборгованість компанії перед клієнтом цілком нормальна навіть в довгостроковій перспективі. Але для книжкового інтернет-магазину це допустимо лише як тимчасова ситуація. Якщо це сталося, магазин повинен постаратися якомога швидше погасити заборгованість.
У звичайній ситуації, щоб виплатити борг клієнту, книжковий інтернет-магазин відправляє зворотний рахунок-фактуру. Ці рахунки обробляються групами – ось що мала на увазі бухгалтер, коли сказала: «Я подивилася журнал дебіторської заборгованості …» Коли Джо Тестер зробив своє антизамовлення, система інтернет-магазину відправила платіж у розмірі -$39 в журнал дебіторської заборгованості, що відразу створило борг компанії перед Джо. Наступної ночі система обробляє журнал, знаходить неоплачений борг і створює зворотний рахунок-фактуру, який потрібно відправити Джо, щоб обнулити його баланс в журналі. Це фактично означає, що наш тестовий клієнт отримує оплату (рисунок 2.4). Це рахунок-фактура, що прониклива бухгалтерка вважала підозрілою і через яку у неї виникали питання.
Перевірки проводилися в реальних умовах, тому очевидно, що виявлений розрив існував в системі вже деякий час. Цей конкретний випадок був виявлений тільки через підозрілу адресу. Але подібні випадки могли статися і раніше.
Було розпочато фінансове розслідування, щоб визначити, наскільки серйозною була проблема. Оперативна група та команди безпеки об’єднали зусилля, щоб перехресно перевірити всі створені рахунки-фактури на повернення. Після відсіювання рахунків-фактур для постачальників і партнерів залишилися тільки записи клієнтів. Більшість з них були правильними і пояснювалися пошкодженням товару або іншими зрозумілими причинами. Залишилася невелика частина, тому проблема була не надто серйозною – по крайней мере, так здавалося в той момент. Проте сам факт того, що безоплатна відправка грошей залишилася непоміченою, був дивним. Технічне розслідування продовжувало розкривати всі подробиці того, що відбувалося при замовленні антикнижки. Виявилося, що в цьому процесі задіяні ще дві важливі системи: складська і диспетчерська.
Система складського обліку відстежує, скільки примірників тієї чи іншої книги є на складі і доступно для продажу. Для початку можна було б визначити кількість штук кожного видання на складських полицях, але, на жаль, виявилося, що все не так просто. Уявіть, наприклад, що у нас в наявності 17 примірників «Гамлета». Клієнт купив два з них, але їх ще не забрали з полиці і не відправили. Ці книги не слід рахувати, оскільки вони не доступні для продажу, і магазин більше не володіє ними. В наявності має бути 15, а не 17 примірників «Гамлета».
Ще одна гіпотетична ситуація полягає в тому, що полиця, призначена для роману «Гордість і упередження», виявилася порожньою. Магазин вже купив у видавця 100 примірників, але вантажівка з ними ще не доїхала до складу. Оскільки ці книги є власністю магазину, вони доступні для продажу і повинні бути в наявності. Тобто в наявності має бути 100 примірників Pride and Prejudice, а не 0. Може виникнути багато інших дивних ситуацій.
Система складського обліку має складну логіку.
Після продажу трьох примірників «Гамлета» інтернет-магазин відправить повідомлення в систему управління запасами про зменшення кількості примірників «Гамлета» з 15 до 12. Але що, якщо замість цього Джо Тестер купить книгу -1? Кількість наявних одиниць «Гамлета» дорівнювала 15 і повинна була зменшитися на -1 до 16 (рис. 2.5). Продаж одного анти-«Гамлета» збільшує кількість доступних примірників на 1!
Диспетчерська система стежить за тим, щоб клієнти отримували свої книги. Коли інтернет-магазин формує замовлення, система відправки сортує його позиції і складає список, згідно з яким працівники складу повинні упакувати товар. Це складна система, яка намагається мінімізувати працю працівників, дозволяючи їм, наприклад, збирати книги відразу під кілька замовлень. Процес добре оптимізований.
Однак система подачі не дуже добре справляється з негативною кількістю книг. Такий пункт в замовленні призводить до виключення, яке записується в системний журнал разом з багатьма іншими повідомленнями. На жаль, ніхто ніколи не заглядає в цей журнал. Пункт замовлення фактично скасовано.
Системи вірять в ту саму брехню
Вимальовується цікава картина. З фінансової точки зору інформаційні системи гармонізовані між собою. Системи білінгу і доставки не так важливі, так як не змінюють свій стан. Нас більше цікавить система складського обліку та журнал дебіторської заборгованості.
Система складського обліку помилково вважає, що є 16 екземплярів «Гам літа», хоча насправді їх 15.
Журнал дебіторської заборгованості помилково вважає, що магазин повинен комусь гроші.
З фінансової точки зору ці факти врівноважують один одного: замість 15 книг і нульового боргу магазин отримує 16 книг і борг, рівний ціні однієї книги. Обидві системи помиляються, але вони вірять в одну і ту ж брехню. Ця ілюзія послідовна.
Оскільки системи узгоджені, регулярні звіти не показують розбіжностей. Насправді, деякі з них генеруються щоночі, а інші, які є частиною фінансової звітності, є квартальними. І ніяких невідповідностей ні в одному з них немає, так як в інформаційних системах їх просто не існувало. Є невідповідності, але тільки у вигляді невідповідностей між системою складського обліку (16 книг) і фактичною кількістю книг на складі (15). Але помітити це можна було тільки після проведення інвентаризації, яка проводиться в кінці року. Він передбачає ручний підрахунок товару на складі з подальшим внесенням його в систему обліку. Тільки це дозволило б помітити відсутню книгу.
Однак немає нічого дивного в виявлених в ході щорічної інвентаризації розбіжностей. Книги – це фізичні об’єкти, і багато чого може статися на складі. Наприклад, постачальник може завантажити 133 книги замість 134. Іноді трапляється виправити не всі ящики або помилитися при підрахунку. Книгу можна впустити, пошкодити і викинути. Це слід зазначити в системі, але іноді люди поспішають і забувають це зробити. Також можлива крадіжка. Фінансовий відділ класифікує все це як «втрачено на складі», і певний рівень таких втрат цілком очікуваний.
Власне кажучи, щорічна інвентаризація, проведена кількома місяцями раніше, показала, що втрати на складі зросли. Керівництво вирішило, що причина у відсутності мотивації працівників складу: можливо, вони стали менш уважними і пошкодили більше книг, а може, почали красти книги. В результаті керівництво відправило їх на одноденний ретрит з мотиваційним тренером, щоб узгодити свої цінності з етикою компанії. Працівники складу були здивовані і не дуже задоволені.
При подальшому розслідуванні невідповідностей все виявилося гірше, ніж виглядало спочатку. Виявлені на складі розбіжності значно перевищили загальну кількість накладних на повернення. Але це також не був кінець.
Зрозумівши, що регулярним звітам не можна довіряти, команда безпеки почала поглиблене розслідування. Виявилося, що отримання зворотної накладної було не найпоширенішим способом оперування цим дефектом. Набагато більшою популярністю користувалися саморобні знижки у вигляді додавання негативних книг перед оформленням замовлення, що зменшувало його загальну суму (рис. 2.6). Очевидно, чутки про цю незвичайну можливість поширилися по інтернету, так як нею скористалися чимало клієнтів.
Розслідування показало, що компанія втратила значну суму грошей через цю лазівку. Настав час вирішити, що з цим робити.
До технічного дефекту ми повернемося трохи пізніше. Але як бути з грошима, які клієнти винні компанії, надаючи собі знижки? В кінцевому підсумку рішення про це приймає рада директорів. Після ретельного аналізу ситуації було прийнято рішення залишити все як є. Похід за клієнтами, серед яких багато постійних, викличе у них неприязнь до компанії і принесе більше шкоди, ніж якщо просто прийняти втрати, залатати діру і рухатися вперед.
Безперервне порушення ділової доброчесності тривало місяцями, незважаючи на те, що формально все було в порядку. І це, швидше за все, залишилося б непоміченим, якби не допитливий співробітник бухгалтерії і тестувальник безпеки, який цікавився бізнес-процесами (предметна область, пов’язана з продажем книг). Ми переконані, що сьогодні в усьому світі можна знайти безліч таких дефектів, які постійно використовуються, не викликаючи ніяких підозр.
Очевидно, що компанія, яка втрачає гроші таким чином, має проблему безпеки. Але з чого все починається? І, що ще важливіше, як цього уникнути? Наші спостереження показують, що подібні ситуації часто є результатом процесу моделювання, який передчасно зупиняється на першій більш-менш підходящій моделі. Такий процес характеризується недостатньо глибоким аналізом, некритичним підходом, відсутністю планування та обговорення. Ми назвемо це конкретно стиль моделювання поверхні (який є протилежністю глибокого моделювання).
Для початку давайте запитаємо себе: «Що може викликати таку проблему?» Озираючись назад, ми розуміємо, що кількість книг не можна було зробити необмеженим цілим числом. Але чому цей аспект був розроблений саме так? Як згадувалося в главі 1, дизайн охоплює всі свідомі рішення, які приймаються при розробці програмного забезпечення. При цьому в рамках проектування було свідомо вирішено, що величина повинна бути у вигляді необмеженого цілого числа. Можливо, це рішення було не дуже обдуманим, але, подобається вам це чи ні, але хтось його прийняв.
Давайте розглянемо інші поняття, пов’язані з дизайном – їх досить багато в сфері книжкових продажів. Деякі з них важливі, інші не так важливі. У процесі проектування ми вибираємо концепції, які будуть грати центральну роль, такі як замовлення, предмети замовлення, книга і кількість. Часто доводиться спостерігати, як дизайн фокусується на питанні «Як це відобразити в коді?». У таких випадках проектні рішення зводяться до пошуку шляхів реалізації концепцій. Коли такий спосіб знайдений, роботу можна вважати завершеною. І в цьому випадку найкоротший шлях від бізнес-понять до коду досягається за рахунок використання елементарних типів мови: цілих чисел, чисел з плаваючою комою, булевих значень і рядків (рис. 2.7).
Аспекти домену представлені по-різному: деякі явно, інші неявно. Наприклад, наша модель має таке поняття, як наказ, а замовлення має грошову оцінку. Він також містить предмети, кожен з яких має книгу і кількість. Книга має назву, номер ISBN і ціну. Замовлення, замовлення товару та книги є явними поняттями в нашій предметній області. І кількість, ім’я, ISBN і price є неявними поняттями і представлені цілими числами, рядками і т. Д. Іншими словами, кількість – це ціле число без обмежень. Якщо дивитися на речі таким чином, може здатися дивним, що і порядок, і пункт замовлення, і книга були детально описані, а кількість так і залишилося звичайним цілим числом. Чому так сталося?
Нам здається, що багато хто з цих помилок зводяться до того, що процес моделювання не був завершений або не проводився зовсім. Уявіть собі розмову продавця на ім’я Марк Етолог і розробника на ім’я Коді Ровщик на ранніх стадіях проекту. У них може бути щось на зразок цього діалогу.
«І тоді ви можете додати книги до замовлення», – каже Марк.
«Як ми можемо описати книгу?» – запитує Коді.
«Друкуємо назву і ціну», – відповідає Марк.
“Якою може бути ціна? Це завжди ціле число?” – не заспокоюється Коуді.
– Ну, ні. Книга може коштувати, наприклад, $ 19,5 без урахування податків », – розповідає Марк.
Коді стверджує: «Як атрибути, книга має назву і ціну. Заголовок буде рядком. Ціна буде реальним, а не цілим числом».
ОБЕРЕЖНО. Ніколи, ні в якому разі, не уявляйте собі гроші у вигляді числа з плаваючою комою! Щоб з’ясувати чому, прочитайте бічну панель «Гроші та подвійний тип» у розділі 12.
Коді запитує: «Це все про книгу?»
“Ні, – відповідає Марк, – також важливо включити номер ISBN, щоб ми могли розділити книги в твердій палітурці та м’якій обкладинці”.
“Гаразд. Потім ми додаємо до замовлення книги, — каже Коді, — наприклад, «Мобі Дік», «Гордість і упередження», «Гамлет», «Знову Мобі Дік», «1984» і знову «Мобі Дік»?
– Ну, майже. Ми просто перераховуємо три екземпляри «Мобі Діка», і нам все одно, в якому порядку вони купуються.
«Гаразд, – думає Коуді, – це не реальне число, це ціле число».
ОБЕРЕЖНО. Будьте підозрілі до симуляцій, які закінчуються словами “це ціле число”!
Пізніше це обговорення перетворилося на код. Коді створив клас Book із атрибутами title, isbn та price. У класі Order з’явився новий метод, addOrderLine(Book book, int quantity). Оскільки замовлення, позиція замовлення та книга мають явні уявлення, всі вони стають класами. Система типів гарантує, що вони будуть використовуватись у відповідних ділянках коду. Якщо туди, де очікується Book, передати щось інше, вийде помилка компіляції.
І це кількість неявно представлено елементарним типом int. Застосування цей атрибут не контролюється системою типів або компілятором. Ви можете випадково передати якесь інше ціле число, наприклад, температуру на вулиці, і компілятор не помилиться. На те, що ми очікуємо отримати кількість, вказує лише ім’я аргументу quantity:
Відзначимо, що під час розмови Коді не ставив ніяких додаткових питань про ISBN або про те, як називається книга. Він відразу зробив висновок, що це звичайний текст, а в коді ці атрибути представлені типом String. А ось ISBN і, швидше за все, ім’я не може бути ніякими рядками.
Коли справа доходить до моделювання, Коді не некомпетентний. Він задав цікаве питання про природу ціни: «Чи завжди це ціле число?» – але не став заглиблюватися. Крім того, він зовсім не помітив натяку на те, що ціна може бути складніше, коли Марк відповів: «… без урахування податків”. Коуді, здається, в першу чергу стурбований тим, як це буде представлено в коді, а не тим, як це працює.
Ми бачили, як моделювання поверхні призводить до того, що цікаві бізнес-концепції реалізуються у вигляді примітивів: цілих і дійсних чисел, рядків, булевих значень і т. д. Як показує наш досвід, такого роду неявні уявлення досить широко поширені. Ми часто стикаємося з системами, в яких практично все представлено за допомогою рядків, цілих чисел і дійсних чисел. На жаль, це має негативні наслідки.
Ви вже знаєте, що проста річ, що представляє величину з правильним цілим числом, може викликати серйозні проблеми з безпекою. Цей тип не має важливих обмежень. Аналогічно, використання необмеженої кількості рядків для назв книг і номерів ISBN дає занадто багато простору для зловживань. Якщо системі, яка очікує отримати правильно відформатований номер ISBN, передається щось інше, може статися щось дивне.
ОБЕРЕЖНО. Будь-яке ціле число від -2 до 2 мільярдів є поганою ідеєю для більшості речей.
Номер кредитної картки та номер соціального страхування (SSN) є ще двома поширеними прикладами того, як неявні поняття можуть бути представлені у вигляді рядків. Очевидно, що ми ризикуємо отримати дані, які не є дійсним номером кредитної картки або SSN, і вони можуть бути навіть у неправильному форматі. Але що ще гірше, так це те, що ви можете обробити їх неправильно.
Номери кредитних карток і SSN мають суворі обмеження щодо того, як їх можна публікувати, реєструвати і т. д. Якщо представити їх у вигляді рядків, є ризик, що вони випадково потраплять до запису в журналі або відображатимуться на екрані. Пізніше ви побачите, як представлення таких сутностей за допомогою класів домену може запобігти таким помилкам. Наприклад, ми можемо використовувати одноразові об’єкти читання (про це піде мова в главі 5).
Але повернемося до наших понять, представленим у вигляді примітивів мови. Такі уявлення можуть привести до створення дуже непривабливого коду. Погляньте на наступний підпис методу:
void addCust(ім’я рядка, телефон рядка, рядок факс, int creditStatus, int vipLevel, рядковий контакт, рядок contactPhone, логічний партнер)
Цей код має всього вісім параметрів, але якщо випадково поміняти місцями два з них, клієнт може отримати кредитний статус або рівень послуг, на які він не має права. Оскільки creditStatus і vipLevel int, компілятор не помітить, якщо ви вкажете їх у неправильному порядку. Такі помилки можуть привести до неявних дефектів, які важко виявити, іноді загрозливі безпеці. Вісім параметрів – не такий вже й довгий список. Нам траплялися підписи з десятками параметрів, кожен з яких був рядком. Особливо поширена ця проблема для дизайнерів.
Поверхневе моделювання і неявні поняття, які воно заохочує, значно збільшують ризик написання неправильного і небезпечного коду. Альтернативою є більш продуманий, глибокий підхід до моделювання і використання явних понять. Тепер давайте подивимося, як би виглядала ця історія, якби працівники свідомо намагалися впровадити глибокі моделі.
Щоб зрозуміти, що таке глибоке моделювання, потрібно спочатку прийняти той факт, що будь-яка створена вами модель є результатом вибору. У будь-якій предметній області існує незліченна кількість різних потенційних моделей. В ході проектування ви вибираєте набір понять, на яких будете будувати і вкладати в них певний сенс. Щоб використовувати термінологію доменного дизайну, цей конкретний вибір є Модель домену (або модель домену) – це необхідна сутність домену. Наша робота в галузі безпеки та дизайну значною мірою натхненна специфічним підходом, який заохочує глибоке розуміння та суворе моделювання домену.
Цілеспрямовані зусилля в області моделювання мають на увазі активне вивчення предметної області. Слід не прагнути до реалізації концепцій, а розбиратися в них. Це робить обговорення моделей набагато глибше і часто призводить до ітеративного процесу, що складається з комунікації та кодування. В результаті можна виділити більше понять, без явного уявлення про які неможливо повністю охопити всі характеристики вашої моделі.
Повернемося до діалогу Коді Ровщика і Марка Етолога і подивимося, як би він виглядав в контексті глибокого моделювання.
«І тоді ви можете додати книги до замовлення», – каже Марк.
«Як ми можемо описати книгу?» – запитує Коді.
«Друкуємо назву і ціну», – відповідає Марк.
“Якою може бути ціна? Це завжди ціле число?” – не заспокоюється Коуді.
– Ну, ні. Книга може коштувати, наприклад, $ 19,5 без урахування податків », – розповідає Марк.
Коді стверджує: «Як атрибути, книга має назву і ціну. Сама ціна виглядає досить складно, адже ви згадали про податки. Мені доведеться подумати про це пізніше». І він запитує: “Це все про книгу?”
“Ні, – відповідає Марк, – також важливо включити номер ISBN, щоб ми могли розділити книги в твердій палітурці та м’якій обкладинці”.
“Гаразд. Потім ми додаємо до замовлення книги, — каже Коді, — наприклад, «Мобі Дік», «Гордість і упередження», «Гамлет», «Знову Мобі Дік», «1984» і знову «Мобі Дік»?
– Ну, майже. Ми просто перераховуємо три екземпляри «Мобі Діка», і нам все одно, в якому порядку вони купуються.
«Чи можу я купити половину «Мобі Діка?» – запитує Коді.
– Звичайно, ні, яка нісенітниця!
«Ви згадали слово «кількість», – каже Коуді. «Я хочу краще це зрозуміти. Що станеться, якщо спочатку додати три «Мобі Діка», а потім видалити їх усі? Чи отримаємо ми нульові копії «Мобі Діка»?
– Е-е, не зовсім. Тобто число нуля – це зовсім не величина. Ми б просто видалили його», — каже Марк.
«Здається, що це число має якісь правила, – каже Коді. – Наскільки вона може бути великою? Два мільярди книг?”
“Ха-ха. Звичайно, ні. Серйозно, наскільки я пам’ятаю, потік книг, який проходить через магазин, обмежений і ми не можемо приймати замовлення з кількістю, що перевищує 240 одиниць.
“Потік книг проходить через магазин?”
“Так, саме так вони це називають. Саме так обробляються замовлення, зроблені в інтернет-магазині, на складі. Йдеться про розміри коробок, пакувальному цеху і так далі. Більші замовлення повинні оброблятися масовим потоком. Але він недоступний в інтернет-магазині», — пояснює Сол.
“Що означає загальна кількість у замовленні? Можете навести приклад?”
«Це просто сукупна кількість книг. Якщо у вас є три «Гамлета», чотири копії «Гордості і упередження» і один «Мобі Дік», то всього вісім», – відповідає Марк.
ПОРАДА. Під час моделювання не забувайте обговорювати верхні межі – це завжди дозволяє отримати цікаву інформацію. Коді зазначає, що індивідуальна кількість не може перевищувати 240, і те ж саме стосується загальної кількості в замовленні.
Пізніше ця інформація втілюється в коді:
В ході глибокого моделювання можна виділити ще багато цікавих концепцій, занадто цікавих, щоб їх можна було залишити неявними. Як правило, ми рекомендуємо зробити неявні поняття явними. Якщо ви зіткнулися з таким неявним поняттям, як «кількість» у своїй історії, знайдіть пару хвилин, щоб обговорити його глибше. Якщо вона здається вам досить цікавою, зробіть її явною – опишіть як частину вашого дизайнерського рішення. Пізніше, при написанні коду, кількість прийме форму окремого класу і буде застосовувати свої власні межі. Крім того, використання цієї концепції зробить іншу частину коду більш виразною.
Поширеним запереченням є те, що якщо зробити всі ці поняття явними, то вийде багато класів. Але слід зазначити, що код в цих класах потрібен в будь-якому випадку: всі варті уваги бізнес-правила повинні бути імплементовані в код, інакше якість системи погіршиться. Реалізація явних понять у вигляді класів впливає на організацію вашого коду. Якщо цікавить вас поняття розкидано по декількох класах, Його складніше знайти.
ПОРАДА. При моделюванні робіть явними неявні поняття.
Моделювання поверхні – це втрачена можливість дізнатися щось важливе. Як ви бачили, це також може бути потенційним джерелом вразливостей безпеки. Щоб скористатися цією можливістю, слід задати питання: «Що мається на увазі під кількістю? Чи існують різні типи кількості? Чи є якісь обмеження?” Ви, швидше за все, дізнаєтеся, що кількість книг не може бути негативним. Можливо, вам навіть вдасться дізнатися, що вона не дорівнює нулю, тому що «слово «кількість» ми вживаємо з числом тільки тоді, коли є книги, інакше вважається, що кількості немає взагалі».
Питання про нижню межу можуть привести до обговорення верхньої межі. Чи розумно дозволяти додавати до замовлення 2 147 483 647 книг? Почувши таке питання, профільний експерт може пояснити, як працює логістика, як завантажуються книги на піддони і т. д. Дискусія поглибить ваше розуміння процесів і ще більше знизить ризик виникнення проблем доброчесності бізнесу.
Такий підхід до проектування робить результат набагато виразнішим, стійким і менш сприйнятливим до вразливостей безпеки. У наступних розділах ми спробуємо пояснити, як цього досягти і які принципи проектування є найбільш ефективними для уникнення вразливостей. Давайте почнемо з розгляду деяких концепцій дизайну, специфічних для домену, які виявилися найбільш корисними.
Неповне, відсутнє або поверхове моделювання призводить до появи проектного рішення з дефектами в галузі безпеки.
Дефект безпеки у вигляді порушеної бізнес-цілісності може існувати в промисловому середовищі протягом тривалого часу, викликаючи фінансові втрати.
Свідоме, цілеспрямоване проектування дозволяє отримати набагато більше надійне рішення.
Ми використовували матеріали з книги “Безпека by design”, які написали Дэн Берг Джонсон, Дэниел Деоган, Дэниел Савано.
1272 
1150 
1008 
942 
962 
927 
1020 