І почну з головного: не ставтеся до інформаційної безпеки легковажно. Я дуже часто чую дві фрази. Перша — «ми не цікаві зловмисникам». Але будь-який бізнес завжди у зоні ризику. Інцидент означає втрату прибутку, значні витрати ресурсів на відновлення і репутаційні ризики. Репутація будується важко, а втрачається легко. Якщо дивитися глобально, картина інша. Ви працюєте і сплачуєте податки, які йдуть на підтримку ЗСУ та інших сфер. Інцидент, що призвів до скорочення прибутку, впливає на податки. Відповідно, чим менше податків, тим менший бюджет, тим менше можливостей у країни.
Друга фраза — «у нас усе добре працює». Можливо. Але зловмисники розвиваються так само швидко, як і технології. Тому задумайтеся, коли ви востаннє робили security review? Коли дивилися глибоко на процеси, інструменти й тенденції. Коли востаннє перевіряли внутрішній периметр?
Щоб ці слова не звучали абстрактно, наведу кілька цифр із галузевих звітів за 2025–2026 роки. За звітом IBM Cost of a Data Breach 2025, глобальна середня вартість витоку даних становить близько $4,44 млн, а в США — рекордні $10,22 млн. Середній час виявлення й локалізації інциденту — 241 день, тобто майже вісім місяців, поки атакувальник уже всередині. Вразливість, яку виправляють у продакшені, коштує приблизно у 100 разів дорожче, ніж та сама вразливість, закладена й виправлена на етапі архітектури. Це відоме «правило 1-10-100» (IBM Systems Sciences Institute). Ось чому варто почати захищатися вчасно.
Що закладати в архітектуру на старті
Для найкращого розуміння потрібно заглибитися в проєкт. Зрозуміти, чому він важливий, у чому його цінність для бізнесу. Без цього будь-які поради з безпеки будуть загальними й марними.
Далі починається конкретика. Знаєте, яка у вас архітектура: фізичний сервер чи хмара (AWS, Azure, GCP)? Які будуть операційні системи? Наступним кроком буде знайти інформацію про вразливості саме вашого сетапу і варіанти їх усунення. Далі треба спланувати покриття контролями безпеки та налаштування. Я раджу відштовхуватися від CIS Benchmarks. У SharksCode ми беремо їх за базову точку і адаптуємо під конкретний сетап проєкту. Там є рекомендації з налаштування різних систем під різні потреби.
Потім вам потрібна карта архітектури та мережі. Уже відповідно до неї формуються профілі доступу, RBAC та впроваджується MFA. Доступи потрібно регулярно переглядати на актуальність, видавати новим співробітникам і вчасно відкликати, коли людина йде або змінює роль. Те саме на рівні мережі. Визначаєте, що дозволено, а що заборонено, і фіксуєте ці правила в документації. Одразу закладайте це як постійний процес.
Якщо бізнес планує отримувати сертифікати (ISO 270xx, PCI DSS, SOC 2 чи інші), варто вивчити або повторити, які контролі мають бути відповідно до сертифікації.
Наступний крок — зробити BIA (аналіз впливу на бізнес), щоб зрозуміти, що найкритичніше у вашому продукті, системі чи проєкті. Далі слід порахувати, скільки коштуватиме непрацездатність того, над чим ви працюєте. Після аналізу переходьте до threat modeling (ще до написання коду), щоб зрозуміти можливі вектори атак і слабкі місця.
Ще не забувайте закладати Change Management в свої процеси. Кожна зміна має документуватися, має бути власник, рев’юер та той, хто затверджує. Необхідно додавати докази зроблених змін.
План мінімізації ризиків
Зазвичай радять «розробити план мінімізації ризиків». Порада гарна, але без конкретики абсолютно некорисна. Тому додаю конкретику.
Люди
Проаналізуйте наявні ресурси. Чи достатньо у вас людей, які працюватимуть над інформаційною безпекою — SOC, AppSec, DevSecOps, GRC? Чи потрібні всі вони одразу? Вирішувати вам залежно від проєкту. Головне — розуміти, хто відповідатиме за безпеку ще до старту.
Інструменти
Далі питання інструментів. Якщо їх ще немає, варто заздалегідь визначитися зі стратегією: йти в бік платних рішень чи open source. З платними зазвичай простіше. Вони легше інтегруються і мають більше функцій. З open source історія інша. Покрити всі потреби проєкту самими лише опенсорсними інструментами насправді дуже важко. На їхнє налаштування та зшивання з рештою систем йде чимало часу. У SharksCode ми комбінуємо обидва підходи залежно від потреб конкретного продукту.
Стійкість і відновлення
А тепер уявіть, що сайт упав через атаку. Чи є у вас план Б? Тут працюють BCP, DRP, бекапи, дзеркалювання — усе, що дозволяє швидко відновитися або хоча б мінімізувати втрати, ще не забувайте перевіряти ваші бекапи чи дійсно ви зможете з них відновитись та скільки часу це займає бо кожна хвилина може коштувати багато для компанії. За захист на рівні трафіку відповідають Firewall чи WAF. До таких сценаріїв варто бути готовим заздалегідь.
Логування та постійний моніторинг
Окремо винесу моніторинг, бо це ваша перша лінія захисту. Він визначає, чи побачите ви проблему завчасно, чи дізнаєтеся про неї вже за фактом, а то й від самих користувачів.
Потрібно врахувати в логуванні ваші деплої, підтвердження комітів або доступів, будь-які зміни, неуспішні входи в акаунт та дії з привілегіями. Щодо постійного моніторингу. Тут потрібно слідкувати за вразливостями та виправляти їх, моніторити периметри та інциденти, реагувати на інциденти.
Безпека в конвеєрі розробки
Відповідно до рекомендацій NIST SP 800-218 (Secure Software Development Framework) можна розділити на такі етапи:
1. Підготовка
- Визначення ролей і відповідальності.
- Документація та політики SSDLC.
- Навчання технічної команди (Dev, DevOps, QA, Architects…)
- Інвентаризація інструментів
- Вимоги до постачальників ПЗ
2. Захист продукту
- Захист вихідного коду.
- Контроль доступу до репозиторіїв.
- Захист CI/CD.
- Захист артефактів збірки.
- Управління секретами.
3. Розробка захищеного продукту
Вимоги до безпеки продукту закладаються на етапі планування.
Моделювання загроз.
Перевірка безпеки архітектури.
Захищене написання коду.
Експертна перевірка.
Перевірка безпеки коду.
SAST, SCA, Secret scanning, DAST.
Тестування безпеки перед релізом.
4. Реагування на вразливості
- Постійний моніторинг вразливостей.
- Пріоритизація та усунення.
- Аналіз першопричин.
- Повторна перевірка після виправлень.
- Координація розкриття інформації про вразливості.
Тут я б додав два коментарі. Перший — завести інструменти, з якими реально працюватимете: SAST, DAST, SCA, VM і pentest. Другий — прийняти для себе підхід shift-left security, тобто посунути перевірки безпеки якомога ближче до початку розробки. Чим раніше виявите проблему, тим дешевше вона вам обійдеться. За даними IBM, виправлення на етапі тестування коштує приблизно в 15 разів дорожче, ніж на етапі проєктування, а в продакшені — уже до 100 разів.
Базові рішення, які потім дорого міняти
Є категорія архітектурних рішень, які на старті коштують дешево, а після запуску — дуже дорого. Йдеться про автентифікацію, авторизацію, сегментацію тощо. Давайте предметно.
Наприклад, доступ до вашої хмари зараз відкритий без VPN і ви вирішили це виправити. Чи буде вплив на бізнес? Можливо, доведеться платити за VPN, з’явиться
додатковий крок, щоб потрапити в хмару, і буде потрібен ресурс того, хто це налаштує. Але загалом це нормальний робочий процес, якщо зайнятися цим на старті.
А тепер інша сторона. Ваш продукт уже працює й приносить гроші. У якийсь момент з’являється критична вразливість, яку можна виправити лише, зупинивши сервіс. Зупинка робочого сервісу завжди призводить до прямих фінансових втрат. Тут бізнесу треба вирішити: втрачати прибуток чи приймати ризик.
Або ще приклад. Ви не використовували шифрування певних даних, а тепер через регуляції чи сертифікацію це необхідно впровадити. Подібні маніпуляції передбачають великі зміни в коді та інфраструктурі, які заберуть багато ресурсів. Обидві ситуації не виникли б, якби рішення заклали на початку.
Принципи, що працюють на практиці
За роки роботи я для себе впевнився в тому що ці три принципи, справді дають результат. Ці принципи входять до фундаменту сучасної інформаційної безпеки. Також багато міжнародних стандартів брали за основу ці принципи. Чому ми з вами про них зараз говоримо, все просто це принципи які визначають як повинні проектуватись процеси, системи,програмне забезпечення та інфраструктура на архітектурному рівні.
Secure by default — принцип, за яким система з коробки має бути в максимально захищеній конфігурації. На практиці це означає розумні дефолти. Закладати це варто саме на старті, бо тоді безпека масштабується разом із продуктом природно.
OWASP рекомендує за замовчуванням вмикати TLS, security headers, приватні мережі, безпечні криптографічні налаштування та deny by default. Я, своєю чергою, можу ще додати MFA, парольну політику, Audit logs. Трішки про плюси і мінуси, які можуть бути.
Плюси:
- Зменшує кількість помилок конфігурації. (Більшість витоків даних пов’язана саме з неправильними налаштуваннями, а не з помилками у програмному коді.)
- Забезпечує гарний стартовий рівень безпеки. (Нові середовища одразу відповідають базовим вимогам безпеки.)
- Прискорює безпечне розгортання. (Усі команди використовують єдині базові конфігурації.)
Мінуси
- Менша гнучкість. (Безпечні налаштування можуть не відповідати окремим бізнес-сценаріям і вимагати додаткових винятків.)
- Вищий початковий поріг. (Розробники можуть сприймати суворі політики як перешкоду, особливо в середовищах розробки.)
Рекомендації:
- Використовувати hardened baseline-конфігурації для серверів, контейнерів і хмарних сервісів;
- Вмикати шифрування, журналювання, MFA та безпечні мережеві налаштування за замовчуванням;
- Автоматизувати перевірку конфігурацій через Infrastructure as Code та політики CI/CD;
- Регулярно оновлювати базові конфігурації відповідно до нових рекомендацій NIST, OWASP і вимог стандартів.
Least privilege — це принцип, за яким кожен користувач, сервіс, процес або система отримує лише ті права доступу, які необхідні для виконання конкретного завдання, і не більше. Цей принцип називають одним із найефективніших способів зменшення площі атаки. «Мені подобається, як воно працює, люди бігають, суєтяться». Приклад того, що може бути, якщо нехтувати цим принципом: до вас прийшла нова людина і ви дали їй максимальні доступи, щоб не витрачати час потім. А людина виявилася від конкурента і скопіювала код, бази даних, дізналася про ваші нові фічі. Якби ви видали мінімально необхідні права, цієї ситуації можна було б уникнути. Плюси і мінуси погнали!
Плюси:
- Зменшує площу атаки. (Якщо акаунт скомпрометовано, зловмисник не отримує повного контролю над системою.)
- Зменшує ризик випадкових помилок. (Найчастіше інциденти виникають не через хакерів, а через людські помилки.)
- Полегшує аудит
- Покращує відповідність вимогам. (Практично всі великі стандарти прямо або опосередковано вимагають Least Privilege.)
Мінуси:
- Висока адміністративна складність. (Підтримка такого середовища потребує зрілого процесу керування доступом.)
- Може сповільнювати роботу команд.
- Потребує постійного перегляду. (Якщо права регулярно не переглядати, виникає Privilege Creep — поступове накопичення зайвих дозволів.)
Рекомендації:
- Використовувати RBAC або ABAC;
- Впровадити Just-in-Time Access для адміністративних операцій;
- Розділяти звичайні та привілейовані облікові записи;
- Проводити регулярні (наприклад, щоквартальні) ревізії прав доступу;
- Автоматично відкликати невикористовувані привілеї.
Defense in depth — OWASP описує цей принцип як поєднання мережевої ізоляції, автентифікації, авторизації, перевірки введення, шифрування, моніторингу та інших механізмів так, щоб відмова одного рівня не призводила до компрометації всієї системи.
Типові рівні захисту — фізична безпека, мережева сегментація, Firewall/WAF, IAM, MFA, шифрування, Secure Coding, аудит, логування, SIEM, EDR, резервне копіювання.
На мою думку, стратегія, у яку варто вкладати час і ресурси й свідомо закладати в архітектуру проєкту. Її суть у ешелонуванні. Ви вибудовуєте кілька незалежних шарів контролів (на рівні мережі, застосунку, даних та ідентифікації). Будь-який окремий рубіж рано чи пізно пробивають. Треба зробити так, щоб за ним стояв наступний, який зупинить або хоча б сповільнить атакувальника й дасть вам час зреагувати. Останні плюси і мінуси.
Плюси:
- Відсутність єдиної точки відмови. (Компрометація одного контролю не означає компрометацію всієї системи.)
- Підвищує стійкість до сучасних атак. (Атаки зазвичай складаються з кількох етапів. Кожен додатковий рівень збільшує складність атаки та шанси її виявлення).
- Покращує можливості виявлення Мінуси:
- Висока вартість.
- Зростання складності
- Хибне відчуття безпеки. (Велика кількість інструментів не гарантує ефективний захист, якщо вони неправильно налаштовані або не контролюються).
Рекомендації:
- Поєднувати мережеву сегментацію, MFA, шифрування, Secure Coding, SAST/DAST, WAF, SIEM та EDR;
- Регулярно перевіряти ефективність кожного рівня захисту за допомогою penetration testing і tabletop exercises;
- Уникати дублювання контролів без додаткової користі.
Технічний борг безпеки
Він накопичується найшвидше там, де багато залежностей. Наприклад, у роботі з продуктовими командами. Звісно, нові фічі для бізнесу пріоритетніші. Але важливо знайти спільну мову й у кожному спринті брати певний відсоток задач на закриття вразливостей. У SharksCode це закладено в робочий процес команд. Інакше борг зростає тихо, а віддавати його доводиться під час інциденту.
Як організувати security review до запуску
Якщо спиратися на стандарти, наприклад, PCI DSS, SOC 2, NIST, то всі вони нам скажуть, що потрібно впроваджувати Shift Left підхід. Недарма впровадження безпеки на початку дуже допомагає вашому продукту захиститися й масштабуватися в майбутньому. Кожен зі стандартів описує по-своєму процес security review, але спробую показати, що спільного в рекомендаціях та додам своє бачення цього процесу.
Рекомендації:
1. Перевірка Архітектури
- Перевірка моделі архітектури.
- Сегментація.
- Мережеві налаштування.
- Криптографія.
- Керування Секретами.
2. Моделювання загроз
- Визначення активів.
- Сценарії атак.
- Оцінка ризиків.
- Затвердження або коригування заходів захисту.
3. Перевірка коду
- Відповідність стандартам безпечного написання коду.
- Логіка автентифікації та авторизації.
- Обробка помилок.
- Валідація введення.
- Використання криптографії.
4. Перевірка інфраструктури
- Перевірка Infrastructure as Code.
- Конфігурації, наприклад, Kubernetes.
- Перевірка Terraform.
- Перевірка IAM.
- Мережеві політики та налаштування.
Моє бачення процесу:
Якщо описувати на рівні принципів, то review починається з аудиту процесів і налаштувань інфраструктури. Далі йдуть сканування та пентести, перевірка заведених вразливостей. На момент релізу не має лишатися незакритих критичних і високих. І нарешті, підтвердження, що всі конфігурації безпеки та контролю доступу налаштовані правильно.
Все це не робота одного відділу. Найбільше залучена команда Information Security, але поруч обов’язково працюють Dev, DevOps і Product. У SharksCode ми вибудували процес саме так, бо без їхнього контексту перевірка буде неповною.
Окремо варто сказати про баланс автоматизації та ручного аналізу (SAST, DAST, SCA, pentest, code review). Що і коли застосовувати, залежить від продукту, але найкраще вони працюють у парі. Автоматика дає масштаб і швидкість, а ручний аналіз — глибину й контекст, яких інструмент просто не бачить.
І показово, що «діри», які найчастіше знаходять перед релізом, — це далеко не щось екзотичне. Зазвичай збережені секрети, токени чи облікові дані, які забули прибрати з коду або системних файлів, дефолтні користувачі, відкриті порти. Саме через свою буденність вони так легко й доходять до продакшену.
Процес і люди
Як вбудувати безпеку в цикл розробки, не ставши «відділом гальмування»? Скажу чесно, що деякі процеси трохи сповільняться. Так і має бути. Нам із вами потрібно не бігти, а усвідомлено рухатися в правильному напрямку.
По-перше, узгодьте процес із Dev, QA, PM, DevOps та іншими командами. По-друге, дайте час на його обкатку, щоб усі спробували, як воно працює на практиці. По-третє, зберіть зворотний зв’язок і покращіть процес. Через кілька ітерацій ви отримаєте саме той процес, який підходить вашій команді. Так свого часу формувався підхід і в SharksCode.
Роль Head of Platform and Application Security і security-команди — це тісна співпраця з командами, а не контроль згори. Разом визначаємо обсяг робіт і все, що використовуватиметься. Далі я допомагаю формувати задачі з погляду безпеки: що закласти в архітектуру. Коли архітектуру підняли, налаштували за рекомендаціями, підняли сервіси й усе необхідне, починається інтеграція систем безпеки. І тільки після цього, власне, перевірка безпеки.
Критерії готовності до запуску
Критерії готовності до запуску складаються з кількох послідовних перевірок. Спершу ми аналізуємо архітектурні зміни та їхній вплив на безпеку, а тоді дивимося на результати автоматизованих перевірок — SAST, DAST, Software Composition Analysis, Infrastructure-as-Code Scanning та Secret Scanning. Далі оцінюємо критичні й високі вразливості і статус їх усунення, перевіряємо налаштування інфраструктури, конфігурації безпеки та контролю доступу. І вже на основі всього цього підтверджуємо готовність до релізу або визначаємо, які коригувальні заходи потрібні перед запуском.
Замість висновку
Найкраща практика для сучасної організації — побудувати Secure SDLC, що відповідає рекомендаціям стандартів. Такий підхід дозволяє одночасно підвищити рівень безпеки розробки, спростити проходження аудитів і зменшити ризик появи вразливостей ще до потрапляння коду у production.
Трішки роздумів з мого досвіду: щоб побудувати ефективну й продуману інформаційну безпеку на проєкті чи в компанії, починати треба на самому старті. У сучасному світі мало знати інструменти, техніки та стратегії. Потрібно ще стежити за новинами, тенденціями й розвитком суміжних сфер.
Вам необхідно розуміти бізнес, а для цього бути максимально залученим до більшості процесів. Що приносить прибуток? Які дні й години найбільш навантажені? Які є інтеграції та підрядники? Будь-яка інформація корисна для аналізу, а на його основі можна зрозуміти слабкі місця системи й побудувати робочу стратегію захисту. І окремо
— комунікація всередині компанії: культура інформаційної безпеки має бути закладена для всіх, незалежно від рівня та позиції. Не забувайте про внутрішній периметр.
Ще дуже Вам раджу періодично переглядати та вдосконалювати процеси. Потрібно змінюватися разом з технологіями та підходами. Цікавтеся різними стандартами та підходами, пробуйте планово впроваджувати щось нове, але не в продакшені, протестуйте спочатку всередині.
Дайте вгадаю, ви прочитали цей текст і думаєте: «Я сподівався, що мені покроково розкажуть, як зробити безпеку на всі сто». По-перше, ста відсотків не буває. Ми маємо намагатися наблизитися до цього значення, але гарантувати його, на жаль, не можна. По-друге, щоб радити щось справді дієве, потрібне повне розуміння продукту, процесів і бізнесу. Те, що працює на нашому проєкті, може не працювати на вашому.
Я поділився своїм досвідом і спостереженнями. Покрокову інструкцію на основі загальних практик може згенерувати навіть ШІ, але без вашого контексту немає гарантії, що вона вам підійде. Тому найкращим варіантом буде пробувати й впроваджувати крок за кроком саме те, що працює для вашого бізнесу.
/
Всім привіт. Мене звати Максим, я Head of Platform and Application Security у SharksCode — українській ліцензованій IT-компанії, яка розробляє високотехнологічні програмні рішення та платформи для B2B за західними стандартами й міжнародними принципами.
Зараз трохи розповім про інформаційну та кібербезпеку. Точніше, про своє бачення того, як зробити ваш проєкт або продукт більш захищеним.
Було б красиво почати з реального кейсу зі свого досвіду, але тут є нюанс — усі випадки різні, як і збитки від них. Тому замість однієї історії я спробую дати поради, які можна застосувати незалежно від масштабу.
