Разграничение доступа по филиалам: роли и контуры данных

В чем проблема: данные смешиваются между подразделениями

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

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

Идея «просто сделаем разные папки» звучит логично, но обычно не работает. Папки решают только место хранения, а не правила доступа. Документы пересылают в мессенджеры и почту, выгружают в Excel, прикладывают в задачи, отправляют подрядчикам, а права потом забывают снять. Если у сотрудника доступ к системе шире, чем нужно, папки уже не спасают.

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

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

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

Термины без путаницы: филиалы, юрлица и «контуры»

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

Филиал - это место и операционная единица: офис в другом городе, склад, отделение банка, региональная дирекция. У филиала могут быть свои сотрудники, процессы, бюджеты, но с точки зрения права он может быть частью одного юрлица.

Юридическое лицо - это граница ответственности и договоров: отдельные счета, налоги, контракты с контрагентами, проверяемая отчетность. Поэтому разделение доступа по юридическим лицам часто строже: сотрудники одного юрлица не должны видеть первичные документы другого, даже если сидят в одном здании.

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

Что такое «контур данных» простыми словами

Контур данных - это граница, внутри которой данные считаются «своими» и доступны группе людей по понятным правилам. Вне контура данные считаются «чужими» и закрыты по умолчанию.

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

Объекты доступа: что именно нужно защищать

Разграничение работает только тогда, когда вы перечислили объекты доступа, а не ограничились абстрактным «доступом к системе». Обычно в периметр попадают документы (договоры, счета, приказы, первичка), заявки и обращения (на закупку, ремонт, ИТ, кадровые запросы), отчеты и аналитика (включая выгрузки и дашборды), базы и справочники (контрагенты, сотрудники, номенклатура), а также почта и файлы (вложения, общие папки, архивы).

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

Какие модели доступа бывают и как выбрать

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

RBAC: доступ по ролям

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

Но RBAC плохо закрывает «границы» (филиал, юрлицо, проект). Если у вас 12 филиалов и 8 юрлиц, роль «Бухгалтер» быстро превращается в десятки вариантов («Бухгалтер-Алматы-Юрлицо-1» и так далее). Матрица прав раздувается, а ошибки становятся неизбежными.

ABAC: доступ по атрибутам

ABAC строится на атрибутах пользователя и данных. У пользователя могут быть атрибуты «филиал», «юрлицо», «должность», «проект». Запись в системе тоже содержит такие поля. Правило звучит так: «можно читать, если филиал совпадает» или «можно проводить платежи, если юрлицо совпадает и должность = бухгалтер».

ABAC особенно полезен, когда людей много, они переходят между подразделениями, а данные постоянно создаются. Вы меняете атрибут у сотрудника или правило, и доступ перестраивается без создания новых ролей.

«Контуры» данных: границы доступа к данным

Контур лучше понимать не как папку или раздел меню, а как правило доступа к данным. Например, контур «Филиал А» означает: записи с меткой «Филиал А» доступны только тем, у кого такой же атрибут. Это можно применить к заявкам, документам, клиентам, инцидентам и даже отчетам.

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

Чтобы выбрать модель, проверьте:

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

Пример: в сети клиник врач должен видеть записи только своего филиала, а финансовый отдел головного офиса - агрегированную отчетность по всем. Роли задают действия (просмотр, редактирование, утверждение), а контуры и атрибуты задают границы (филиал, юрлицо, проект).

Схема ролей: как спроектировать так, чтобы не разрасталась

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

Соберите перечень повторяющихся функций: бухгалтерия, HR, продажи, склад, ИТ, руководители. Затем опишите для каждой функции 5-10 типовых действий в системе: просмотр, создание, согласование, выгрузка отчетов. Так роли получаются «по делу», а не «по фамилиям».

Глобальные и локальные роли

Чтобы роли не разрастались, разделите их на два слоя.

Глобальные роли (администратор платформы, служба безопасности, аудит, поддержка) действуют везде, но с аккуратным набором прав. Локальные роли (бухгалтер филиала, HR юрлица, менеджер продаж конкретного подразделения) работают только внутри своего филиала или юридического лица. Роли руководителей часто не дают «супер-доступ», а позволяют видеть сводные отчеты и согласовывать заявки, тоже в своем контуре. Технические роли (интеграции и сервисные учетные записи) лучше держать отдельно от человеческих.

Ключевой прием: одинаковая роль должна вести себя одинаково. Если «Менеджер продаж» в одном филиале может удалять сделки, а в другом - нет, это уже две разные роли. Их лучше назвать по-разному, чтобы не путаться.

Исключения: задайте правила заранее

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

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

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

Контуры данных: как отделить «свои» данные от «чужих»

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

Маркировка как основа

Начните не с ролей, а с маркировки данных. У каждой сущности (документ, заявка, договор, карточка сотрудника) должны быть поля, по которым система сможет отделить «свое» от «чужого».

Обычно хватает 4-5 меток: юрлицо (владелец данных), филиал (место возникновения или обслуживания), подразделение или центр ответственности, проект/договор (если есть проектная работа), уровень чувствительности (например: обычные, персональные, коммерческая тайна).

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

Хранение и справочники: где можно общее, а где нельзя

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

Частая причина утечек - справочники. Их удобно делить на общие и локальные. Номенклатура может быть общей (если закупки централизованы), а сотрудники почти всегда локальные. Контрагенты часто требуют гибридного подхода: общий справочник, но с привязкой к юрлицу и правилами, кто может видеть «чужие» карточки.

Для сквозных процессов (центральная бухгалтерия, ИБ, закупки) держите принцип минимально необходимого доступа. Давайте доступ не «ко всему юрлицу», а к нужным операциям и только к тем полям, которые требуются для работы. Это особенно важно, если вы внедряете разграничение доступа по филиалам в ERP, документообороте или сервис-деске.

Не забудьте про архив и историю. Старые документы часто оставляют «всем видно», потому что так проще. Лучше задать отдельные правила: кто имеет право видеть архив, можно ли скачивать, что делать при смене структуры (слияние филиалов, перенос сотрудников). Практичная мера - хранить историческую привязку (юрлицо/филиал на момент создания), а не перезаписывать ее задним числом.

Пошагово: как внедрить разграничение доступа

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

Подготовка: сначала понять, где реально ходят данные

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

Пример: менеджер в филиале Алматы создает договор, а бухгалтерия в головном офисе проводит оплату. Если не прописать этот «переход», можно либо заблокировать оплату, либо открыть бухгалтерии все договоры всех филиалов.

Настройка: матрица доступа и правила не только «на компьютерах»

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

Дальше двигайтесь по настройкам:

• разведите учетные записи и группы по филиалам и юрлицам (например, «Продажи-Алматы», «Бухгалтерия-Юрлицо-1»), чтобы права выдавались группами, а не вручную;
• включите контроль там, где живут данные: в приложениях, базах, файловых хранилищах и почте (ограничения «только на ПК» легко обходятся копированием и пересылкой);
• настройте правила по умолчанию: новый пользователь видит только свой контур, расширение доступа идет через согласование;
• зафиксируйте владельцев данных: кто может разрешать доступ к контуру (обычно руководитель подразделения или владелец процесса);
• опишите исключения: временный доступ, замещение на отпуск, доступ аудитора, доступ подрядчика.

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

Перед запуском в рабочую среду прогоните сценарии. Попросите по 2-3 человека из разных филиалов выполнить типовые задачи (создать документ, согласовать, найти, выгрузить отчет) и проверьте два результата: «свои данные доступны» и «чужие не видны даже случайно». Если ломается хотя бы один сценарий, возвращайтесь к матрице, а не выдавайте права «на всякий случай».

Проверки и контроль: как заметить утечку до того, как станет поздно

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

Простые тесты «вижу/не вижу»

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

• Тестовый пользователь филиала А видит только свои карточки, договоры, счета, отчеты.
• Тестовый пользователь филиала Б - то же самое в своем контуре.
• Пользователь головного офиса видит сводную картину там, где это действительно нужно по регламенту.
• Поиск «чужого» объекта по номеру/ФИО/ИИН/БИН ничего не находит.
• Выгрузка отчета «по всем филиалам» недоступна, если роль этого не предполагает.

Проверяйте не только экраны, но и «обходные» места: экспорт в Excel/CSV, печатные формы, общие справочники, а также отчеты и витрины данных. Часто утечка происходит не в карточке, а в отчете, который строится без фильтра по филиалу.

Журналы: что фиксировать и зачем

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

Практичный минимум: выделите перечень «чувствительных» объектов (зарплаты, персональные данные, финансовые отчеты, медданные) и логируйте доступ к ним глубже, чем к обычным справочникам. Так вы не утонете в событиях и быстрее найдете подозрительное.

Регулярные ревизии и временный доступ

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

Временный доступ оформляйте как «срок + цель». Хорошая практика: доступ выдается на 7-30 дней и закрывается автоматически, если его не продлили.

Разбор инцидентов: быстро восстановить картину

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

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

Типовые ошибки и ловушки, которые приводят к утечкам

Самые неприятные утечки случаются не из-за «взлома», а из-за удобства, спешки и забытых настроек. Разграничение доступа по филиалам часто ломается в мелочах: один лишний доступ, одна общая папка, один перевод сотрудника без пересмотра прав.

Ошибки, которые встречаются чаще всего

Обычно проблемы начинаются с одной из этих ситуаций:

• «Суперпользователь» без ограничений по юрлицу и филиалу. Такой аккаунт быстро становится привычным решением для поддержки, бухгалтерии или админа, и в итоге люди видят данные «чужого» контура.
• Копирование данных в общие папки и чаты «для удобства». Даже если исходная система настроена правильно, выгрузка в общий канал или общий диск обнуляет правила.
• Наследование прав в папках, проектах и командах, которое никто не проверяет. Права тянутся «по цепочке» годами, владельцы меняются, а причин доступа уже никто не помнит.
• Одинаковые названия объектов без явной маркировки (например, «Филиал1», «Филиал2»). Люди выбирают не тот объект, прикрепляют не тот файл, отправляют не туда, и ошибка выглядит как обычная операция.
• Увольнения и переводы без своевременного пересмотра доступов. Человек уже в другом подразделении, но его права остались прежними, особенно если доступы выдавались напрямую, а не через роль.

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

Сценарий из практики: подрядчик помогает филиалу А с отчетом, просит выгрузку, менеджер кидает файл в общий чат «чтобы быстрее». Файл видит филиал Б, а в названии только «Отчет_январь.xlsx». Формально никто не «взламывал», но контуры данных уже смешались.

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

Короткий чек-лист перед запуском

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

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

Дальше убедитесь, что роли не разрослись и не дублируют друг друга. Если две роли дают почти одинаковые права, люди будут получать «на всякий случай» обе, и смысл RBAC потеряется. Тут помогает матрица доступа: роли по строкам, ресурсы и действия по столбцам.

Короткий набор проверок перед запуском:

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

После технической настройки сделайте «проверку на соседа». Простой сценарий: пользователь филиала А пытается найти клиента филиала Б по ИИН/БИН или номеру договора. Если поиск что-то показывает, даже без права редактирования, это сигнал: контуры данных разделены не до конца.

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

Пример на практике и следующие шаги

Представим компанию с центральной бухгалтерией и двумя филиалами. Филиал А и филиал Б работают как разные юридические лица. При этом кадровики, бухгалтеры и руководители хотят работать в одной системе, но без риска, что документы одного юрлица «протекут» в другое.

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

Как разделить документы по контурам данных

Счета, договоры и первичные документы проще всего привязывать к обязательным атрибутам: «Юрлицо», «Филиал», иногда еще «Проект» или «ЦФО». Тогда правило звучит просто: сотрудник видит только записи своего юрлица (и, при необходимости, своего филиала), а общие справочники (например, номенклатура) остаются общими.

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

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

Временный доступ без постоянной дыры

Период замещения сотрудника - частая причина утечек. Рабочая схема - временная роль или временное расширение контура с четкими границами.

Например:

• срок доступа фиксируется (дата начала и окончания);
• доступ выдают только на конкретный процесс (например, «проведение платежей»), а не «все подряд»;
• все действия попадают в журнал и регулярно просматриваются.

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

Если на этапе пилота становится ясно, что не хватает мощности или надежности инфраструктуры, полезно подключать системного интегратора. Например, GSE.kz как производитель и интегратор в Казахстане помогает с подбором серверов, рабочих станций и развертыванием инфраструктуры, чтобы контроль доступа работал стабильно и поддерживался в режиме 24/7.