Мультитенантность в SaaS: почему данные вашей пивоварни не должны утекать к конкурентам

Одна база, десятки пивоварен: как это вообще работает

Представьте коммунальную кухню, где десять пивоваров одновременно варят разные стили. У каждого свои ингредиенты, свои рецепты, свой график затирания. Всё происходит в одном помещении — но никто не должен случайно бросить ваш каскадный хмель в чужой стаут. Примерно так работает мультитенантная архитектура в SaaS: множество клиентов (тенантов) используют одну и ту же инфраструктуру, но данные каждого логически — а иногда и физически — изолированы друг от друга.

Для облачных ERP-систем в пивоварении и виноделии это стандартная модель. Она позволяет поставщику держать стоимость подписки на разумном уровне (вам не нужен отдельный сервер за $500/мес), быстро обновлять продукт для всех клиентов сразу и масштабироваться без боли. Но у медали есть обратная сторона — если изоляция данных реализована небрежно, ваши рецепты, маржинальность и контакты поставщиков могут оказаться доступны совершенно посторонним людям.

Что именно может утечь и почему это критично

Когда речь заходит об утечках данных, большинство владельцев пивоварен думают о кредитных картах и паролях. Но в контексте крафтового производства список чувствительной информации куда шире:

• Рецептуры и техкарты — ваш флагманский Hazy IPA с нестандартным профилем сухого охмеления при 18°C — это интеллектуальная собственность. Если конкурент из соседнего города получит доступ к точным навескам, температурным паузам и графику внесения хмеля, он сможет воспроизвести ваш бестселлер.
• Параметры ферментации — логи температуры, плотности, pH по каждой варке. Для опытного пивовара это не просто цифры — это карта, по которой можно воспроизвести характер пива.
• Данные о поставщиках и закупочные цены — если вы нашли фермера, который поставляет локальный ячмень по отличной цене, эта информация имеет прямую коммерческую ценность.
• Объёмы продаж и маржинальность по SKU — зная, какие позиции в вашей линейке самые прибыльные, конкурент может целенаправленно атаковать именно эти сегменты.
• Клиентская база — контакты баров, ресторанов, дистрибьюторов.

Для виноделен список ещё длиннее: данные о виноградных лотах, параметры выдержки в конкретных бочках, купажные формулы, привязка к винтажу. Утечка купажной карты элитного красного — это не абстрактная угроза, это прямые финансовые потери.

Как ломается изоляция: реальные сценарии

1. Небезопасные прямые ссылки на объекты (IDOR)

Самый распространённый баг в мультитенантных приложениях. Допустим, вы открываете свою варку #42 по адресу /api/brews/42. Что произойдёт, если вы вручную поменяете 42 на 43? В плохо спроектированной системе вы увидите варку другой пивоварни — со всеми параметрами, рецептурой и заметками пивовара. Сервер не проверил, принадлежит ли объект #43 вашему тенанту.

2. Утечки через поисковые и фильтрующие эндпоинты

Эндпоинт списка заказов возвращает все заказы из базы, а фильтрация по тенанту происходит только на фронтенде. Любой, кто умеет пользоваться DevTools в браузере, видит весь поток данных. Это не «хакерская атака» — это пятиминутная задача для любопытного пользователя.

3. Проблемы с ролевой моделью (RBAC)

Оператор линии розлива не должен видеть P&L отчёты, а бухгалтер — менять рецептуры. Но если ролевая модель проверяется только в интерфейсе и не подкреплена серверной валидацией, любой авторизованный пользователь с минимальными техническими навыками может вызвать API-эндпоинт напрямую и получить данные, которые ему не предназначены.

4. Утечка хешей паролей и учётных данных

API, возвращающий профиль пользователя, «случайно» включает в ответ хеш пароля или внутренние токены. Технически это не сразу даёт доступ к аккаунту, но открывает дорогу для офлайн-атаки перебором — особенно если пароль был слабым.

Что должна делать SaaS-платформа для настоящей изоляции

Хорошая мультитенантная архитектура — это не один волшебный параметр, а система из нескольких уровней защиты. Вот чек-лист, по которому стоит оценивать любую облачную ERP:

Серверная фильтрация на каждом запросе

Каждый SQL-запрос, каждый вызов API должен содержать фильтр по идентификатору тенанта. Не «на большинстве эндпоинтов», а на каждом без исключения. Это должно быть реализовано на уровне middleware или ORM, чтобы разработчик физически не мог забыть добавить фильтр в новый эндпоинт.

Строгая ролевая модель с серверной проверкой

Роли (владелец, пивовар, менеджер склада, бухгалтер) проверяются на сервере при каждом запросе. Интерфейс скрывает лишние кнопки для удобства, но реальным барьером является бэкенд.

Защита учётных данных

Хеши паролей никогда не покидают базу данных. API-ответы содержат только ту информацию, которая нужна клиентскому приложению. Никаких «лишних» полей «на всякий случай».

Автоматизированное тестирование изоляции

Ручные проверки — это хорошо. Но настоящую уверенность даёт только автоматизированный набор регрессионных тестов, который при каждом обновлении кода проверяет: пользователь тенанта A не может прочитать, изменить или удалить данные тенанта B. Если тест упал — релиз не выходит.

Регулярные аудиты безопасности

Код меняется, добавляются новые функции, появляются новые эндпоинты. Без периодического аудита (хотя бы после каждого крупного релиза) слепые пятна неизбежны.

Как мы решали эту задачу в BrewERP

Будем честны: ни одна система не рождается идеальной. В марте 2026 года мы провели полный QA-аудит BrewERP — 80+ тестов, охвативших более 30 API-эндпоинтов. Результат: шесть критических уязвимостей, включая именно те сценарии, о которых мы говорили выше — недостаточная изоляция данных между тенантами, утечка хешей паролей в API-ответах, пробелы в проверке RBAC-разрешений на бэкенде, потенциальная утечка учётных данных.

Все шесть уязвимостей были исправлены в течение одного дня. Но главное — мы не остановились на фиксах. По результатам аудита написан полный набор автоматизированных регрессионных тестов, которые запускаются при каждом деплое. Теперь любое изменение в коде автоматически проверяется на нарушение изоляции данных. Ваши рецепты, варки, параметры ферментации и финансовые отчёты физически недоступны другим тенантам — не потому что мы «обещаем», а потому что это проверяется автоматически при каждом обновлении.

Практический чек-лист: вопросы вашему SaaS-поставщику

Если вы выбираете облачную систему для управления пивоварней или винодельней, задайте поставщику эти вопросы. Уклончивые ответы — красный флаг:

1. Как реализована изоляция данных между клиентами? — ждите конкретики: фильтрация на уровне ORM, middleware, row-level security в БД.
2. Проводился ли аудит безопасности? Когда последний раз? — «мы планируем» — не ответ.
3. Есть ли автоматизированные тесты на межтенантный доступ? — если нет, каждый новый релиз потенциально открывает дыру.
4. Что произойдёт, если я через API запрошу данные чужой варки? — правильный ответ: 403 Forbidden или 404 Not Found, без какой-либо информации о существовании объекта.
5. Как хранятся пароли? — bcrypt, scrypt или Argon2 с адекватным cost-фактором. MD5 или SHA-256 без соли — уходите сразу.
6. Возвращает ли API хеши паролей или внутренние токены? — единственный допустимый ответ: нет, никогда.

Почему для небольшого производства это особенно важно

У крупного пивоваренного холдинга есть бюджет на собственную IT-инфраструктуру, on-premise серверы и штатного безопасника. У крафтовой пивоварни на 10–50 гектолитров в месяц или бутикового винодельческого хозяйства такого бюджета нет. Вы доверяете свои данные SaaS-платформе — и это нормально, так работает весь современный бизнес. Но доверие должно быть подкреплено конкретными техническими мерами, а не маркетинговыми обещаниями.

Представьте ситуацию: вы потратили полгода на разработку рецепта barrel-aged imperial stout с выдержкой на бочках из-под бурбона. Параметры ферментации, график температурных пауз, точные навески специальных солодов — всё задокументировано в вашей ERP. А через два месяца пивоварня из соседнего города выпускает подозрительно похожий стаут. Совпадение? Может быть. Но если ваша ERP-система не обеспечивает строгую изоляцию данных, «совпадение» — это не единственное объяснение.

Итог: безопасность — это не галочка, а процесс

Мультитенантность — это не проблема сама по себе. Это эффективная архитектура, которая делает облачные инструменты доступными для небольших производств. Проблема — в качестве реализации. Изоляция данных, ролевая модель, защита учётных данных, регулярные аудиты и автоматизированные тесты — вот что отличает зрелую платформу от спешно выпущенного MVP.

В BrewERP мы варим софт примерно так же, как вы варите пиво: с вниманием к деталям, контролем на каждом этапе и готовностью переливать в канализацию то, что не прошло проверку качества. Если вы ищете ERP-систему для пивоварни или винодельни и хотите убедиться в безопасности на практике — попробуйте бесплатный 14-дневный триал на brewerp.top. Никаких обязательств, данные карты не нужны. Просто посмотрите, как это работает изнутри.