Монолітні додатки частково втратили прихильність в епоху мікросервісних архітектур, але, можливо, це скоро зміниться. Організації починають звертати увагу не лише на переваги, але й на недоліки використання мікросервісів, в тому числі у контексті безпеки.
Популярність мікросервісів
Початкова мотивація створення програмного забезпечення з пов’язаних модулів, а не єдиного шматка коду для всього додатку, не змінилася. Модульне ПЗ легше розробляти, підтримувати, тестувати, розширювати та повторно використовувати, а поєднання хмарних розгортань із гнучкою розробкою швидко зробило ці переваги ще більш привабливими. Особливо у випадку стартапів, невеликі команди, які мають лише ноутбуки, можуть послуговуватися мікросервісами для швидкого створення інноваційного програмного забезпечення без початкових інвестицій. Для хмарних додатків у контейнерах мікросервіси стали основною архітектурою, а постачальники хмарних послуг швидко переходять до надання готових до використання середовищ і функціональних можливостей для створення розподіленого ПЗ.
Але, попри всі свої переваги, мікросервісна архітектура не є універсальною. Наприклад, у дослідженні кейсу Amazon, її використання виявилося абсолютно неправильним рішенням. Через тип і саму інтенсивність викликів мікросервісів, архітектура на основі безсерверних компонентів Amazon Web Services була повільною, дорогою та непридатною для масштабування на необхідному рівні. Перехід до монолітного додатка призвів до зниження витрат на хмару на 90% і покращення роботи в цьому конкретному випадку.
Цей кейс з’явився у той час, коли все більше організацій почали переглядати свою хмарну стратегію та серйозно зважувати усі «за» та «проти» хмарного розгортання в порівнянні з локальним. Хоча це переважно зумовлено вартістю хмар, вибір архітектури додатка також має серйозні наслідки для безпеки.
Монолітна архітектура: складніше оновити, але легше захистити
Наявність монолітного застосунку, який містить всю базу коду в одному місці, традиційно вважалася поганою інженерною практикою. Зокрема, будь-яка зміна зазвичай вимагає перебудови всієї програми, навіть якщо це лише один рядок коду. Залежно від внутрішньої структури, монолітна архітектура також може бути складною в обслуговуванні, оскільки будь-які зміни можуть порушити функціонування. Також, вона може бути схильною до надмірного розростання, позаяк швидше та безпечніше додати нову функцію, ніж адаптувати або видалити наявну Але з погляду безпеки, і зокрема її тестування, захистити монолітний додаток може бути набагато легше, ніж у випадку з більш розподіленими моделями.
По-перше, поверхня атаки монолітного застосунку зазвичай буде меншою порівняно з архітектурами, де кожен мікросервіс є окремою ціллю. Менш розподілені програми також зазвичай мають менше зовнішніх залежностей, тому більш зрозуміло, що необхідно тестувати. У моноліті вся бізнес-логіка та комунікація між функціями обробляються внутрішньо, а не через потоки викликів API, якими обмінюються фронтенд і бекенд. Для монолітного додатка також легше налаштувати заходи захисту даних, безпеки мережі та інструменти захисту під час виконання, як-от брандмауер вебдодатків (WAF).
Крім того, у цьому випадку спрощується тестування безпеки. Адже тоді команді доступна більша частина або весь вихідний код (часто з тим самим стеком технологій і мовою програмування). Тоді можна застосувати не тільки динамічне тестування безпеки програми (DAST), як-от рішення Invicti та Acunetix, що впроваджують у різні етапи життєвого циклу розробки ПЗ (SDLC), від перших збірок до фінального додатка в продакшні. А також доступне використання статичного тестування безпеки додатків (SAST) і аналізу програмних компонентів (SCA), як-от Mend.io.
Одним із недоліків монолітної архітектури є те, що процес налагодження та усунення недоліків безпеки може бути повільнішим порівняно з мікросервісами. У мікросервісах легше ізолювати та виправити вразливості в конкретній службі (якщо команда розробників має доступ до вихідного коду).
Мінуси та плюси мікросервісів у контексті безпеки
Переваги мікросервісів необхідно порівнювати з багатьма потенційними проблемами безпеки. Згадані проблеми пов’язані з тим, що поверхня атаки розширюється на десятки або сотні незалежних сервісів. На рівні безпеки інфраструктури кожна окрема служба часто працює у власному хмарному контейнері з конкретними службовими інстансами. Вони організовані за допомогою Kubernetes або подібного рішення, що робить важливим захист хмари. Оскільки всі компоненти додатка комунікують через виклики API, їх безпека також має першочергове значення як для операцій, так і для тестування. При цьому автентифікація часто є особливою проблемою. Позаяк кожна служба виступає окремою ціллю, моніторинг є ще одним слабким місцем. Зловмисники потенційно можуть таргетувати окремі сервіси, не зумовлюючи сповіщення про те, що застосунок піддається атаці.
З хмарними додатками легко покладатися на сторонні залежності та служби, які компанія не контролює і може перевіряти лише ззовні, обмежуючи методи до DAST та ручного тестування на проникнення. У поєднанні з тим фактом, що застосунки можуть використовувати кілька мов програмування та технологій, це робить інструменти аналізу коду, такі як SAST і SCA, обмеженими. Навіть якщо команда контролює та здатна перевіряти свою основну базу коду, цього буде недостатньо, щоб охопити всю поверхню атаки.
Як уже згадувалося, перевага мікросервісів полягає в тому, що ізолювати недолік безпеки для певної служби легше, ніж у монолітному додатку. Також простіше застосувати брандмауер або повністю заблокувати службу, якщо не є можливим негайно усунути вразливість. Крім того, служби, як правило, є автономними, що зменшує ризик повної компрометації системи, якщо один компонент програми зламано.
Надійне тестування безпеки програми незалежно від архітектури
Відносна легкість і швидкість створення та модифікації вебдодатків також поширюється на зміни в архітектурі та моделях розгортання. Хоча аспекти розробки програмного забезпечення та інфраструктури таких проєктів часто зрозумілі та керовані, безпека не завжди за ними встигає. Наприклад, якщо додаток переведено на інший стек технологій і мову програмування, наявні інструменти SAST та робочі процеси можуть більше йому не підходити. Або якщо компанія-розробник, яка раніше значною мірою застосовувала SAST для тестування своїх монолітних застосунків, починає створювати ПЗ за допомогою мікросервісів, виявляє, що у них немає DAST для перевірки всього середовища, яке значно покладається на API.
Перевага рішень DAST у тому, що вони здатні сканувати вебдодатки незалежно від їх технологій і архітектур. Але на практиці вони можуть сильно відрізнятися точністю та практичною користю. Наприклад, багато організацій покладаються на хмарні сканери вразливостей для захисту своїх хмарних додатків. Коли вони вирішують перенести частину програмного забезпечення в локальне розгортання, вони часто розуміють, що продукт, який вони використовують, більше не відповідає їх потребам. Подібні сюрпризи можуть також ставатися у випадку руху в сторону мікросервісів, оскільки компанії іноді надто пізно усвідомлюють, що тепер їм потрібно сканувати багато API, з якими їхні інструменти не справляються.
Універсальним варіантом є вибір рішення DAST, яке буде ефективно працювати незалежно від архітектури чи моделі розгортання. Наприклад, лідер серед динамічних сканерів для вебдодатків Invicti дозволяє організаціям вбудовувати тестування безпеки у DevOps конвеєри. Це дозволяє автоматично запускати сканування, підтверджувати вразливості та надсилати звіти про них безпосередньо в системи відстеження помилок. І все це як для хмарних, так і для локальних застосунків з підтримкою перевірок різних типів API.
