Изоляция данных: почему у каждой компании должна быть своя база

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

Для владельца это выглядит так: вы отдаёте кадровые данные, паспорта, СНИЛС, банковские реквизиты и суммы зарплат в чужое хранилище и надеетесь, что фильтр в каждом запросе написан правильно. Вопрос, который стоит задать до подписания договора, звучит скучно: «У вас одна база на всех или своя на каждую компанию?» Ответ на него определяет, что произойдёт, если в коде однажды ошибутся.

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

Два подхода

Способов хранить данные клиентов в облачном сервисе два. Оба рабочие, разница — в цене ошибки.

Общая база с разделением по организациям

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

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

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

Где находится граница: в строке кода. Каждый запрос — это место, где граница либо соблюдена, либо нет.

Отдельная база на компанию

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

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

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

Цена: сложнее обслуживать поставщику — больше баз, больше обновлений, больше копий. Это его работа, но она влияет на то, как быстро выходят новые функции.

В чём разница на практике

Разница не в скорости работы с данными и не в интерфейсе. Она в одном вопросе: сколько усилий нужно, чтобы ваши данные увидел кто-то посторонний.

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

Изоляция данных — это не про недоверие к поставщику. Это про то, что архитектура определяет, какие ошибки возможны, а какие — нет.

Что может пойти не так в общей базе

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

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

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

Массовые операции. Обновление схемы, исправление данных, миграция — операции, которые касаются всех строк таблицы. Ошибка в такой операции затрагивает не одну компанию, а всех клиентов сразу.

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

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

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

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

Что даёт отдельная база

Физическая граница вместо строки в запросе. Чужие данные не «не должны попасть в выборку» — их в этой базе нет.

Понятная выгрузка и удаление. Данные можно выгрузить целиком, а при расторжении договора — уничтожить, и это операция с базой, а не с набором условий.

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

Предсказуемое поведение при доработках. Новый код работает в базе конкретной компании. Ошибка в нём, скорее всего, испортит данные одной организации, а не всех.

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

Меньше взаимного влияния. Тяжёлый отчёт или пересчёт в одной компании не блокирует таблицы другой: блокировки не пересекаются.

Это не значит, что отдельная база автоматически защищает от всех проблем. Она убирает один класс рисков — случайное или ошибочное смешивание данных разных компаний — и делает остальные риски проще для контроля.

Что ещё важно, кроме изоляции

Изоляция — только часть картины. Если поля лежат открытым текстом, а доступ есть у всех сотрудников, отдельная база мало чем поможет.

• Шифрование чувствительных полей. Паспортные данные, СНИЛС, ИНН, адреса и банковские реквизиты должны храниться в зашифрованном виде: тогда даже при доступе к базе их нельзя прочитать как обычный текст.
• Права по должностям и областям данных. Кадровик, бухгалтер и руководитель отдела должны видеть разное. Доступ по умолчанию — минимальный, а не «у кого есть ссылка».
• Журнал действий. Кто открывал и менял данные — вопрос, на который должен быть ответ. Это помогает и при внутреннем разборе, и при проверке.
• Где находятся серверы. Если данные должны храниться в России, это становится критерием выбора, а не деталью.
• Резервные копии. Копии должны делаться регулярно, а восстановление — быть проверенным, а не предполагаемым.
• Порядок расторжения. Заранее понятно, как выгрузить данные и как они уничтожаются, — тогда уход от поставщика не превращается в проблему.

Простое правило: изоляция отвечает на вопрос «где лежат данные», шифрование и права — на вопрос «кто их увидит», журнал — на вопрос «кто их смотрел».

Какие вопросы задать поставщику

Задайте их письменно и сохраните ответы: они пригодятся и при выборе, и позже. Этот список подходит для любого сервиса, не только для нашего.

1. Где физически находятся серверы и в какой стране хранятся данные?
2. Данные всех клиентов лежат в одной базе или у каждой компании своя?
3. Если база общая — как разделяются данные и как это проверяется?
4. Шифруются ли чувствительные поля в базе или шифрование есть только на канале передачи?
5. Кто со стороны поставщика имеет доступ к данным клиентов и фиксируется ли такой доступ?
6. Есть ли журнал действий: кто смотрел, менял, выгружал данные?
7. Как делаются резервные копии и пробовали ли реально восстановить данные из копии?
8. Что происходит с данными при расторжении договора: как их выгрузить и в какие сроки уничтожить?
9. Можно ли ограничить доступ внутри нашей компании — по должностям и подразделениям?
10. Что произойдёт с нашими данными при сбое или ошибке в обновлении?

Как это устроено в SynkNow

SynkNow — операционная система компании: персонал, задачи, проекты, документы и управленческий учёт в одном контуре. По хранению данных у нас выбран второй подход из описанных выше.

• Отдельная база данных у каждой компании. Данные организаций не пересекаются. Это способ хранения, а не настройка, которую можно случайно снять.
• Шифрование чувствительных полей. Паспортные данные, СНИЛС, ИНН, адреса и банковские реквизиты хранятся в зашифрованном виде.
• Права доступа по должностям и областям данных. Директор видит всю компанию, руководитель — свой отдел, сотрудник — свои записи. Кадровые и финансовые данные не открываются тем, кому они не нужны для работы.
• Журнал действий. Видно, кто открывал и менял данные.
• Серверы в России. Данные хранятся на территории страны.
• Ежедневные резервные копии. Восстановление предусмотрено, а не подразумевается.
• Выгрузка и уничтожение по требованию. При расторжении договора данные можно выгрузить, а затем уничтожить — по вашему требованию.

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

Тарифы для ориентира: «Базовый» — 0 ₽. «Профессиональный» — 4 699 ₽ в месяц за 10 сотрудников, далее 549 ₽ за каждого следующего. «Энтерпрайз» — 8 999 ₽ (1 049 ₽ за место), «Энтерпрайз + Финансы» — 13 899 ₽ (1 539 ₽ за место). Пробный период — 15 дней, до 10 сотрудников, доступ получает владелец компании.

Частые вопросы

Отдельная база — это дороже для клиента?

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

У нас два юрлица. Будет одна база или две?

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

Сможем ли мы выгрузить данные, если решим уйти?

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

Видит ли ваша поддержка наши данные?

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

Достаточно ли изоляции, чтобы спать спокойно?

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

Коротко

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

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

В SynkNow у каждой компании отдельная база данных, чувствительные поля шифруются, доступ разграничен по должностям, действия попадают в журнал, серверы находятся в России, резервные копии делаются ежедневно. Начать можно с бесплатного тарифа или пробного периода на 15 дней — и за это время посмотреть, как устроен доступ на ваших данных.