Модель прав доступа к документам: группы и исключения

Зачем вообще нужна модель прав и где чаще всего ломается

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

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

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

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

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

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

Базовые понятия: документы, папки, действия и видимость

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

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

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

Отдельно решите, нужны ли права на «скачать», «распечатать», «поделиться». Если документ содержит персональные данные или коммерческую тайну, эти действия иногда чувствительнее, чем простое чтение: человек может иметь доступ в портале, но не иметь права унести копию наружу.

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

Роли людей: владельцы, админы и согласующие

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

Кто за что отвечает

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

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

ИБ задает правила: какие документы считаются чувствительными, какие сроки хранения действуют, нужен ли запрет на скачивание, как часто делать пересмотр доступов.

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

Кто утверждает доступ, а кто исполняет

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

Чтобы решения не терялись в переписке, достаточно легкой фиксации:

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

Пример: в папку «Договоры» сотруднику продаж дают чтение через группу «Sales - договоры (чтение)» на время испытательного срока, а право редактирования остается только у юристов и владельца раздела.

Группы вместо индивидуальных прав: как правильно организовать

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

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

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

Чтобы через год было понятно, что делает группа, договоритесь о простом именовании. Хорошо работает шаблон: кто + где/что + уровень. Например: «HR Алматы - чтение», «Юристы - правка шаблонов», «Проект DC-2026 - согласование». Из названия должно быть ясно, зачем группа существует и какие права предполагаются.

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

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

Наследование прав: как оно работает и как его не сломать

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

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

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

Рабочее правило - минимум исключений. Можно измерять так: если в разделе больше 10-15% объектов с уникальными правами (не как у родителя), значит структура или группы выбраны неправильно. В таком месте проще создать отдельную папку с отдельным набором прав, чем поддерживать десятки «особых» документов.

Чтобы наследование работало на вас, структуру папок стоит проектировать под доступ, а не под «красивую навигацию». Проверьте:

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

Если вы строите модель так, наследование становится безопасным стандартом, а исключения - редким и понятным случаем, который легко объяснить и проверить.

Исключения и запреты: как делать аккуратно и прозрачно

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

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

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

Чтобы исключения были прозрачными, фиксируйте их как маленькую карточку решения:

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

Главный способ избежать «слоеного пирога» - не делать исключения глубоко в дереве, где они смешиваются с наследованием. Если появляется больше 2-3 исключений в одной ветке, лучше поднять решение выше: выделить отдельную папку «Ограниченное», настроить права на уровне папки и вернуть внизу чистое наследование.

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

Пошагово: как спроектировать модель прав для внутреннего портала

Проектирование прав лучше начинать не с кнопок в админке, а с реальной работы людей. Хорошая модель отвечает на вопрос: кто и что должен делать с документом в обычный день, и что случится, если кто-то ошибется.

5 шагов, которые работают в большинстве компаний

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

2. Нарисуйте дерево уровней: портал -> раздел -> папка -> документ. Для каждого уровня сразу определите базовые группы (например, «HR-редакторы», «Юристы-чтение») и где наследование должно быть включено.

3. Опишите роли и базовые права простыми словами: чтение, редактирование, утверждение, владение. У владельца должна быть обязанность поддерживать порядок, а не «всемогущие права на все».

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

5. Протестируйте на пилотной группе. Дайте людям реальные задачи и попросите отметить два типа проблем: «не могу сделать нужное» и «вижу лишнее».

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

Пример: в компании типа GSE.kz можно начать с трех верхних разделов - «Производство», «Закупки», «ИТ и поддержка». На первом проходе оставьте наследование включенным везде, кроме отдельных папок вроде «Договоры и претензии», и проверьте, что новые сотрудники попадают в группы через отдел, а не через ручные разовые выдачи.

Пример сценария: компания с HR, бухгалтерией и юридическим отделом

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

Группы лучше собирать по устойчивым ролям, а не по людям. Например: HR, Бухгалтерия, Юристы, Руководители (как отдельная группа для расширенной видимости), Все сотрудники (только общие материалы). Тогда вход сотрудника или его перевод между отделами меняет членство в группе, а не десятки ручных галочек.

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

Для чувствительных данных проще завести отдельные закрытые разделы с минимальным набором групп и без лишнего наследования из корня. Например:

• «HR: Личные дела» - доступ только HR и части Руководителей;
• «Финансы: Зарплата и налоги» - только Бухгалтерия и финдиректор;
• «Юристы: Договоры и споры» - только Юристы и назначенные руководители.

Исключение стоит делать заметным и ограниченным по времени. Допустим, пришел внешний аудитор. Ему дают доступ только к папке «Финансы: Аудит 2025», с датой окончания (например, через 14 дней) и запретом на просмотр остальных финансовых папок.

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

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

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

Самые частые ловушки:

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

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

Что помогает на практике:

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

Быстрый чеклист перед запуском и после изменений

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

Короткий чеклист перед релизом и после любого заметного изменения (новая папка, реорганизация отделов, миграция):

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

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

Аудит и поддержка модели прав: чтобы она жила, а не пылилась

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

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

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

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

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

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

Следующие шаги: как внедрять без боли и кто может помочь

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

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

Безопасный порядок действий:

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

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

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

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