Безпека: аудит, захист API та ролі доступу в бойовому контурі

Аудит безпеки, захист API, ролі та права доступу, SSL і захист від атак. Чому прихована кнопка не обмежує доступ і скільки коштує перевірка безпеки застосунку.

Безпека: аудит, захист API та ролі доступу в бойовому контурі
INGELLO / BUSINESS3043

Напрям із блоку корпоративного розвитку: підключається тоді, коли продукт із MVP перетворюється на MMP і MLP. Вартість напряму: $4700.

Безпеку відкладають найчастіше, бо її не видно під час демонстрації. Видно її рівно один раз: коли вже запізно.

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

Що входить

  • Аудит безпеки.
  • Захист API.
  • Ролі та права доступу.
  • SSL, захист від атак.

Аудит безпеки

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

Захист API

Кожен метод API приймає лише дозволені запити від авторизованих користувачів із потрібною роллю. Вхідні дані перевіряються на сервері, частота викликів обмежується, а помилки не розкривають внутрішньої будови системи.

Ролі, SSL і захист від атак

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

Роль обмежує дію, а не зовнішній вигляд

Найпоширеніша помилка в замовних системах: кнопку сховали, а дію залишили відкритою. Перевірка має стояти на сервері, у кожної дії має бути явний перелік ролей і допустимих методів, а операції, що змінюють дані, приймаються лише захищеним запитом.

Тому клієнтська валідація з логіки інтерфейсів слугує зручності користувача, а не захисту. Справжнє обмеження живе в серверній бізнес-логіці.

Бойовий контур відрізняється від тестового

Інструменти розробника на проді мають бути вимкнені, службові адреси закриті, а база внесена до обовʼязкового переліку резервного копіювання з перевіреним відновленням. Це частина інфраструктури, але перевіряється саме під час аудиту.

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

Що отримує бізнес

  • Перелік реальних ризиків системи з пріоритетами, а не загальне «начебто все захищено».
  • Закриті на сервері права: кожна роль бачить і робить лише своє.
  • API, яке не віддає даних без авторизації й витримує перебір.
  • Перевірене відновлення з резервної копії.

Скільки коштує і від чого залежить

Напрям коштує $4700 за фіксованою ціною й охоплює аудит, захист API, ролі та права доступу, SSL і захист від атак. Перед стартом на консультації фіксуємо межі: які дані вважаються чутливими, які ролі є в системі, які зовнішні інтеграції беруть участь в обміні.

Якщо систему робила інша команда й спершу треба зрозуміти її стан, починають з аудиту наявної системи: $800 за текстовий звіт із висновками та переліком ризиків або $2400 із відновленням проєктної картини й раннім прототипом доробки.

Що ламається, якщо заощадити

  • Дані клієнтів доступні за прямою адресою без входу.
  • Співробітник із базовою роллю виконує дії адміністратора, просто надіславши запит в обхід інтерфейсу.
  • Звільнений співробітник зберігає доступ, бо ролі не відкликаються автоматично.
  • Після збою зʼясовується, що резервна копія є, але відновитися з неї неможливо.

Приклади з практики

У системі для мережі медичних центрів дванадцять ролей. Роль обмежує сторінки й дії, а привʼязка до філії обмежує видимі обʼєкти: адміністратор центру не бачить фінансової аналітики, HR бачить персонал усієї мережі, але не пацієнтів і гроші, лікар не бачить P&L. Єдине джерело правди про те, що бачить кожна роль, закрите автотестом, а під час звільнення робочі ролі відкликаються.

MCP-сервер Ingello відкритий для будь-яких ШІ-агентів без авторизації, тому захист API там побудований на обмеженні частоти викликів для кожного інструмента. У Goal Decomposer ключ OpenAI зберігається в браузері користувача й іде на сервер лише на час запиту, сервер його не записує, а сам сервер написаний без зовнішніх залежностей, щоб лишити мінімум поверхні для вразливостей.

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

Куди далі

Суміжні напрями: подієве поглиблення та автоматизація тестування. Карту зібрано в стратегії розробки застосунку.

Замовити аудит безпеки.

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

Поширені питання

01Що перевіряє аудит безпеки вебзастосунку?

Аудит дивиться на систему очима зловмисника: які адреси відкриті, що доступно без входу, чи можна виконати дію чужої ролі запитом в обхід інтерфейсу, як захищене API, де зберігаються секрети, чи ввімкнені SSL і захист від перебору, чи вимкнені інструменти розробника на проді й чи відновлюється база з резервної копії. Підсумок: перелік ризиків із пріоритетами та план виправлень.

02Скільки коштує аудит безпеки застосунку?

У стратегії розробки Ingello напрям «Безпека» коштує $4700 за фіксованою ціною: аудит, захист API, ролі та права доступу, SSL і захист від атак. Якщо спершу треба зрозуміти стан системи, яку робила інша команда, є аудит наявної системи: $800 за текстовий звіт із переліком ризиків або $2400 із раннім прототипом доробки.

03Чому прихована кнопка не захищає від несанкціонованих дій?

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

04Як правильно налаштувати ролі та права доступу в CRM чи ERP?

Роль має обмежувати і сторінки, і дії, а привʼязка до філії чи підрозділу обмежувати видимі дані. Наприклад, у системі для мережі медичних центрів дванадцять ролей: HR бачить персонал усієї мережі, але не пацієнтів і гроші, лікар не бачить P&L. Правила перевіряються автотестом, а під час звільнення робочі ролі відкликаються автоматично.

05Як захистити відкрите API без авторизації користувачів?

Відкрите API захищають обмеженням частоти викликів на кожен метод, суворою перевіркою вхідних даних на сервері й тим, що через нього доступні лише публічні дані та безпечні дії. Так влаштований MCP-сервер Ingello для ШІ-агентів: він працює без авторизації, але з лімітом на кожен інструмент. Помилки не мають розкривати внутрішньої будови системи.