Мультитенантность в менеджере паролей: как крупный бизнес управляет доступами без потери изоляции данных
Представьте ситуацию: холдинг из трёх компаний, единая IT-служба и один корпоративный менеджер паролей на всех. Удобно — пока не выясняется, что инженер, обслуживающий «дочку» в Екатеринбурге, теоретически может найти через поиск учётные данные московского головного офиса. Не потому что злоумышленник. Просто потому что всё лежит в одном пространстве.
Это не гипотетическая история. Это типичная архитектурная проблема, с которой сталкиваются компании, когда стандартный корпоративный менеджер паролей вырастает из своих возможностей вместе с бизнесом.
Решение называется мультитенантность. И в контексте управления паролями это понятие значит куда больше, чем просто «разные папки с разными правами».
Что такое мультитенантность и почему это не то же самое, что права доступа
Мультитенантность — это архитектурный подход, при котором одна система обслуживает несколько независимых групп пользователей с полной изоляцией их данных. Ключевое слово здесь — архитектурной.
Большинство корпоративных менеджеров паролей предлагают изоляцию через права доступа: сотрудник А не видит папку Б, потому что у него нет прав на эту папку. Это работает в простых случаях. Но у этого подхода есть фундаментальное ограничение: изоляция существует на уровне настроек, которые можно выдать не туда, забыть отозвать или обойти через привилегированную учётную запись.
Мультитенантная архитектура работает иначе. Данные разных тенантов физически разделены на уровне системы. Пространство А и пространство Б существуют независимо — и операции внутри одного пространства по определению не могут затронуть данные другого. Не потому что так настроено, а потому что система устроена именно так.
Разница принципиальная — особенно когда речь идёт об аудитах безопасности и требованиях регуляторов. Архитектурную изоляцию значительно проще задокументировать и подтвердить при проверке, чем объяснять логику матрицы прав доступа.
Три сценария, где мультитенантность становится необходимостью
Холдинги и группы компаний
Холдинг — это несколько юридических лиц с разными командами, разными IT-инфраструктурами и разными требованиями к безопасности. При этом единая IT-служба должна администрировать системы централизованно.
Без мультитенантного менеджера паролей выбор невелик: либо одно общее хранилище (нарушает принцип изоляции между юрлицами), либо отдельный экземпляр системы для каждого юрлица (кратно увеличивает операционную нагрузку и стоимость владения).
Мультитенантная архитектура снимает этот выбор: единая установка, единый договор, единая точка администрирования — и при этом полная изоляция данных каждого юридического лица.
IT-аутсорсеры и MSP
Managed Service Provider, обслуживающий десятки корпоративных клиентов, работает с учётными данными каждого из них. Вопрос простой: как гарантировать клиенту, что его данные физически недоступны инженеру, работающему с другим клиентом?
Ответ — только архитектурная изоляция. Отдельное пространство на каждого клиента с независимым управлением, своей ролевой моделью и при необходимости собственной LDAP-интеграцией. Инженер видит только то, с чем работает — и это закреплено не политикой, а архитектурой.
Крупные компании с изолированными подразделениями
Банк с розничным и корпоративным блоками. Производственная компания с разделёнными IT-периметрами. Госструктура с несколькими уровнями доступа. Во всех этих случаях требование одинаковое: сотрудники одного подразделения не должны иметь доступа к учётным данным другого — даже через поиск, даже через экспорт, даже случайно.
Как устроены Пространства в BearPass: разбор по деталям
В версии BearPass 2.26.0 мультитенантность реализована через модуль «Пространства». Разберём как это работает на практике — не в маркетинговых формулировках, а в конкретных механизмах.
Системное пространство и логика запуска
При установке BearPass 2.26.0 автоматически создаётся системное пространство с ID=1 и названием «Общее пространство». Все новые пользователи по умолчанию добавляются в него.
Для тех, кто обновляется с предыдущих версий: все существующие корпоративные папки, пароли и пользователи автоматически привязываются к этому системному пространству. Никакой ручной миграции, никаких потерь данных — система продолжает работать в штатном режиме с первой минуты после обновления.
Важный момент: системное пространство нельзя удалить. Это якорь всей архитектуры, который гарантирует, что ни один пользователь и ни одна запись не окажутся «вне» системы.
Как создать и настроить пространство
Управление пространствами находится в левом навигационном меню консоли администратора. Таблица пространств показывает каждое из них с тремя ключевыми параметрами: уникальный ID, количество участников и количество записей (паролей и папок) внутри.
Создание пространства — это форма с двумя колонками. В левой колонке весь список пользователей системы с поиском по email или имени. В правой колонке — участники конкретного пространства. Перетащить пользователя из одной колонки в другую — значит добавить его в пространство или убрать из него.
Есть важная защита от ошибок: если попытаться удалить пользователя из пространства, которое для него единственное, система заблокирует операцию и покажет предупреждение. Это предотвращает ситуацию, когда сотрудник оказывается вообще без доступа к системе.
Удалить пространство можно только если оно пустое — без папок и паролей внутри. Это логичное ограничение: случайно уничтожить данные целого подразделения не получится.
Модель прав доступа к пространствам
Это самая тонкая и одновременно самая важная часть архитектуры. В BearPass реализованы четыре уровня прав, связанных с пространствами:
«Управление пространствами» — полный контроль над всеми пространствами: создание, редактирование, удаление, управление составом участников. Принципиально важная деталь: это право не даёт доступа к паролям и папкам внутри пространств. Администратор структуры видит, что пространства существуют и кто в них состоит — но не видит содержимое.
«Управление выбранными пространствами» — то же самое, но только для конкретных пространств, явно указанных при назначении права. Администратор филиала в Новосибирске управляет своим пространством и не видит остальные.
«Управление пользователями выбранных пространств и ролей» — самое гранулярное право. Позволяет управлять только теми пользователями, которые одновременно состоят в указанном пространстве и имеют указанную роль. Пример из документации: если выдать право на пространство «Маркетинг» и роль «Администратор», то пользователи пространства «Маркетинг» с ролью «Пользователь» будут недоступны. Пользователи пространства «Разработка» с любой ролью — тоже недоступны.
«Доступ ко всем паролям и папкам» — полный доступ к содержимому внутри выбранных пространств.
Эта четырёхуровневая модель позволяет выстроить тонкое разделение: кто управляет структурой, кто управляет пользователями, кто работает с данными. Три разные роли, три разных уровня доступа — и ни один из них не предполагает автоматически наличие другого.
Что должна обеспечивать мультитенантная архитектура: чеклист для оценки решения
При выборе корпоративного менеджера паролей для холдинговой или многофилиальной структуры стоит проверить каждый из этих пунктов.
🔹 Изоляция охватывает все операции, а не только просмотр. Поиск, импорт, экспорт и LDAP-синхронизация должны работать в границах пространства — иначе изоляция иллюзорна.
🔹 Независимый LDAP для каждого пространства. Критично для холдингов, где у разных юридических лиц разные домены Active Directory. Без этого автоматизировать управление пользователями не получится.
🔹 Разделение административных и операционных прав. Тот, кто управляет структурой пространств, не должен автоматически получать доступ к паролям внутри них. И наоборот.
🔹 Защита от случайного удаления данных. Удаление непустого пространства должно быть заблокировано системой.
🔹 Бесшовный переход. Внедрение мультитенантной архитектуры не должно требовать ручной миграции данных и простоя системы.
🔹 On-premise развёртывание. Для большинства крупных российских компаний, особенно в финансовом секторе и госструктурах, данные не могут покидать периметр.
🔹 Наличие в Реестре ПО Минцифры. Для компаний, подпадающих под требования импортозамещения, это обязательный критерий при закупке.
В BearPass все семь пунктов закрыты.
Три архитектурных сценария: как это выглядит в работе
Холдинг из трёх компаний
Одна установка BearPass. Три пространства — по одному на каждое юридическое лицо. Системный администратор создаёт пространства, настраивает права и синхронизирует каждое из них со своим Active Directory — через независимые LDAP-подключения.
Важный момент по правам: системный администратор имеет право «Управление пространствами» — видит структуру и состав участников, но не видит пароли внутри. Отдельные администраторы каждого юрлица управляют своими пространствами через «Управление выбранными пространствами» — опять же без доступа к паролям других подразделений.
Новый сотрудник в любом юрлице появляется через LDAP-синхронизацию и автоматически попадает в нужное пространство. Уволенный теряет доступ там же — без ручных действий.
IT-аутсорсер с двадцатью клиентами
Одна установка, двадцать пространств. Каждый инженер добавляется только в пространства своих клиентов — остальные для него не существуют даже в интерфейсе. Поиск по паролям не выходит за границы пространства: инженер просто не может найти то, что физически находится в другом контуре.
При добавлении нового клиента создаётся новое пространство. При завершении контракта пространство сначала очищается (пустое пространство — обязательное условие удаления), затем удаляется. История действий сохраняется в журнале.
Банк с двумя изолированными блоками
Розничный и корпоративный блоки работают в отдельных пространствах с независимыми ролевыми моделями. Журнал событий ведётся в границах каждого пространства и экспортируется в SIEM независимо. При аудите безопасности или проверке регулятора изоляция подтверждается не объяснением настроек прав, а архитектурой системы.
Мультитенантность и требования регуляторов
Для компаний в регулируемых отраслях мультитенантная архитектура имеет прямое отношение к соответствию требованиям.
Приказы ФСТЭК №17 и №21 требуют разграничения доступа на основе ролей и документированного управления учётными записями. Архитектурная изоляция пространств обеспечивает выполнение этих требований надёжнее, чем матрица прав доступа — и проще документируется при проверке.
Для организаций, обрабатывающих персональные данные нескольких юридических лиц, пространства помогают разграничить периметры обработки данных. При расследовании инцидента Роскомнадзором архитектурная изоляция — весомый аргумент: вы не просто настроили права, вы выстроили систему, в которой пересечение данных невозможно по архитектуре.
Отдельный фактор для госсектора и КИИ: BearPass включён в Реестр отечественного программного обеспечения Министерства цифрового развития (№15427) и поддерживает шифрование по ГОСТ. Мультитенантную архитектуру BearPass можно применять на объектах, где использование иностранного ПО ограничено или запрещено.
Итог
Мультитенантность в корпоративном менеджере паролей — это конкретная архитектурная характеристика, которая определяет, подходит ли решение для холдинговых и многофилиальных структур.
Ключевые критерии: изоляция на уровне архитектуры, а не прав доступа; независимая LDAP-синхронизация для каждого контура; разделение административных и операционных прав; защита от случайного удаления данных; бесшовный переход без миграции.
Модуль «Пространства» в BearPass 2.26.0 закрывает все эти требования — с документированной архитектурой, которую можно показать при аудите, и on-premise развёртыванием, при котором данные не покидают периметр компании.