Своя изолированная база данных: почему это важно для безопасности компании

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

Большинство SaaS-сервисов по умолчанию складывают данные всех клиентов в одну общую базу, разделяя их лишь идентификатором компании в каждой строке. Логически ваши записи отделены от чужих, но физически они лежат рядом. Такая архитектура удобна разработчику и дешевле в эксплуатации, однако именно она формирует целый класс рисков, о которых заказчик узнаёт только тогда, когда что-то пошло не так. Разберём, почему модель с отдельной изолированной базой данных для каждой компании — это не техническая роскошь, а базовое требование к безопасности.

Что такое общая база и где в ней слабое место

В классической мультитенантной архитектуре все клиенты сервиса живут в одной базе данных. Принадлежность записи конкретной организации определяется полем-меткой: у каждой задачи, каждого документа и каждого пользователя проставлен идентификатор компании. Когда вы открываете свой проект, приложение выполняет запрос вида «покажи всё, где метка равна моей». Пока код работает без ошибок, вы видите только своё.

Проблема в том, что вся изоляция здесь держится на дисциплине программного кода. Достаточно одной забытой проверки в одном запросе, ошибки в фильтре или недочёта при обновлении сервиса — и данные одной компании становятся видны другой. На практике такие утечки между арендаторами (в англоязычной терминологии их называют cross-tenant) — один из самых типичных классов уязвимостей облачных платформ. Стена между вашими данными и данными конкурента существует, но она нарисована в коде, а не выложена из кирпича.

Почему для строительной отрасли это критично

Строительный рынок тесно связан и высококонкурентен. Нередко на одной платформе оказываются компании, которые участвуют в одних и тех же тендерах, работают на смежных объектах или напрямую конкурируют за подряды. В таких условиях утечка проектных данных — это не абстрактный репутационный ущерб, а прямое коммерческое преимущество, отданное сопернику.

Что именно оказывается под угрозой при хранении в общем массиве:

• Проектная и рабочая документация, чертежи и планировки, которые составляют интеллектуальную собственность и коммерческую тайну.
• Сметная логика: объёмы, замечания, сроки и переделки, по которым конкурент может реконструировать вашу экономику проекта.
• Замечания технадзора и история приёмки — фактически карта проблемных мест объекта, чувствительная и для заказчика, и для подрядчика.
• Персональные данные сотрудников и представителей подрядных организаций, за сохранность которых компания отвечает по закону.
• Внутренняя переписка в чате и структура задач, из которой читается организация работы и её узкие места.

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

Изолированная база: другой принцип разделения

Альтернативный подход — выделять каждой компании собственную, физически отдельную базу данных. Это архитектура, которую в СтройОко мы называем изоляцией на уровне базы: при регистрации организации под неё создаётся отдельное хранилище, и данные разных компаний не соседствуют в одних и тех же таблицах даже теоретически.

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

Что это даёт компании на практике

Преимущества изолированной базы выходят за рамки одной только защиты от утечек. Они затрагивают весь жизненный цикл работы с данными:

• Локализация инцидентов. Сбой, ошибка или компрометация в контуре одной организации не распространяется на остальных — у каждого своё хранилище.
• Прозрачный контроль объёма. Понятно, где именно лежат данные вашей компании и что в них входит, что упрощает внутренний аудит и ответы на запросы службы безопасности.
• Аккуратное резервное копирование и восстановление. Бэкап и откат можно выполнять по контуру конкретной компании, не затрагивая чужие данные.
• Чистое расставание с сервисом. При прекращении работы данные организации удаляются как единое целое, а не выковыриваются из общего массива по меткам с риском что-то пропустить или задеть лишнее.
• Управляемая нагрузка. Активность одной крупной компании не упирается в общий с другими лимит и не деградирует чужую производительность.

Для руководителя проекта и ПТО это переводит разговор о безопасности из плоскости обещаний в плоскость проверяемых фактов. Вы можете внятно ответить на вопрос заказчика или собственной ИБ-службы: данные нашей компании находятся в отдельной базе, изолированы от других клиентов платформы, и это заложено в архитектуре, а не поддерживается вручную.

Изоляция — не замена базовой гигиене доступа

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

Именно поэтому изоляцию данных стоит рассматривать как фундамент, поверх которого выстраивается ролевая модель. Когда основа надёжна, настройка прав внутри компании становится осмысленной задачей, а не попыткой компенсировать архитектурную слабость хранилища ограничениями в интерфейсе.

СтройОко изначально спроектирован так, что каждая компания получает собственную изолированную базу данных, а поверх неё — гибкую систему ролей и прав. Проектная документация, чертежи, замечания технадзора и данные сотрудников остаются в вашем отдельном контуре, отделённом от других клиентов на уровне архитектуры, а не только программного фильтра. Если для вас безопасность проектных данных — не формальность, а рабочее требование, это тот случай, когда стоит присмотреться к тому, как устроено хранение под капотом.