Внедрение No-code в Enterprise-сегмент сокращает Time-to-Market внутренних инструментов на 60-80%, но 40% проектов забрасываются на этапе согласования с ИБ из-за отсутствия гранулярного управления доступом. Для корпоративного B2B-инструментария безопасность — это не наличие пароля, а возможность скрыть конкретное поле в БД для одного из десяти уровней ролей.
Критерии безопасности: от базового Auth до RBAC
Для внутренних систем критически важна модель RBAC (Role-Based Access Control). Базовые No-code инструменты предлагают лишь два уровня: «Админ» и «Пользователь», что неприемлемо для компаний с штатом от 50 человек. Профессиональный стек должен поддерживать создание кастомных ролей с правами CRUD (Create, Read, Update, Delete) на уровне отдельных таблиц и даже конкретных строк (Row-level security). Например, в Bubble.io настройка Privacy Rules позволяет ограничить видимость данных так, чтобы менеджер видел только свои сделки, а РОП — весь отдел, что снижает риск утечки данных внутри компании на 70%.
Экспертный вывод: Если инструмент не поддерживает Row-level security «из коробки», вы получите дыру в безопасности, которую придется латать сложными костылями через API-коннекторы, что увеличивает стоимость разработки на 30%.
Сравнение инструментов по глубине разграничения прав
Анализ рынка показывает разрыв между «конструкторами интерфейсов» и «платформами для данных». Glide и Adalo подходят для простых MVP (срок сборки 1-2 недели, стоимость до $100/мес), но их модель прав доступа поверхностна. Для серьезного B2B-инструментария стоит смотреть на AppSheet (Google) или Retool. Retool позволяет интегрировать SSO (SAML, Okta, Active Directory), что критично для Enterprise: администратор не создает 200 аккаунтов вручную, а привязывает доступ к корпоративной почте. Стоимость владения таким решением выше (от $10-50 за пользователя), но затраты на администрирование прав снижаются в 5 раз.
Экспертный вывод: Для систем с количеством пользователей >100 выбирайте инструменты с поддержкой SSO и внешней базой данных (PostgreSQL, MySQL), чтобы не зависеть от проприетарного облака вендора.
Подводные камни хранения данных и комплаенса
Главная ошибка при разработке внутренних систем — хранение чувствительных данных (ФИО, зарплаты, паспортные данные) в облаке No-code платформы. В РФ это прямое нарушение ФЗ-152. Решение — архитектура «Frontend на No-code, Backend на своем сервере». Например, используя Retool или FlutterFlow, вы подключаетесь к своей БД через защищенный туннель. Это позволяет соблюсти требования ИБ и сохранить скорость разработки, сокращая метрики эффективности No-code разработки: расчет ROI и сокращения Time-to-Market на основе жизненного цикла продукта.
Экспертный вывод: Никогда не используйте встроенные таблицы (Internal DB) для хранения PII-данных (Personally Identifiable Information). Только внешняя БД с настроенным шифрованием трафика TLS 1.2+.
Кейс: Автоматизация склада для ритейл-сети
Задача: Создать систему учета для 15 складов и 120 сотрудников. Сценарий с Glide (базовый доступ) привел к тому, что кладовщик мог видеть остатки и цены закупа всех филиалов, что создало риск внутреннего фрода. Переход на связку AppSheet + Google Sheets с настроенными Security Filters позволил ограничить доступ по Email сотрудника: «Видеть только те строки, где Email_Sklad == User_Email». Срок переработки составил 4 рабочих дня, стоимость лицензий — около $10/мес на пользователя, но риск утечки коммерческих цен был сведен к нулю.
Экспертный вывод: Фильтрация данных на стороне сервера (Server-side filtering) — единственный способ обеспечить реальную безопасность. Фильтрация на стороне клиента (UI-скрытие элементов) обходится любым пользователем через консоль браузера за 30 секунд.
Вывод
Для разработки внутренних корпоративных систем забудьте о простых конструкторах. Мой выбор для Enterprise — Retool или AppSheet при условии использования внешней БД. Избегайте инструментов, где права доступа настраиваются только через «видимость элементов интерфейса». Начинайте с проектирования матрицы доступа (кто, что и зачем видит) до первого клика в редакторе, иначе переделка архитектуры безопасности на этапе масштабирования съест до 50% бюджета проекта.