Права доступа в 1С:Документообороте 3.0 при переходе с 2.1 лучше не переносить «как есть», а спроектировать заново: провести аудит текущих групп, описать реальные сценарии «кто какие документы должен видеть», собрать матрицу ролей, проверить её в тестовой базе и только потом переносить пользователей. Иначе в новую систему переедут все накопленные за годы исключения, и через полгода никто снова не сможет сказать, кто что видит.
Ниже — почему права «расползаются», как я провожу пересмотр модели доступа при переходе на ДО 3.0 и на что обратить внимание руководителю и службе безопасности.
Почему права доступа в ДО 2.1 превращаются в хаос
Сценарий узнаваемый. Документооборот работает несколько лет. Права выдавались по запросу: новому сотруднику копировали права «похожего» коллеги или добавляли в какую-то группу, не проверяя, что именно она открывает. Групп становится всё больше, часть создавалась под задачу, которой давно нет.
Признаки, что модель прав пора пересматривать:
- менеджеры видят договоры чужих направлений и клиентов;
- при увольнении учётная запись блокируется, но членство в группах остаётся;
- подключение нового сотрудника занимает дни, потому что администратор вручную подбирает группы;
- логику доступа знают два-три человека, и она нигде не записана;
- служба безопасности не может получить ответ на вопрос «кто видит договоры с грифом».
Это не ошибка платформы, а отсутствие проектирования. Документооборот позволяет построить строгую и понятную модель, но сам её не придумает.
Почему переход на 3.0 — хороший момент
Переход на редакцию 3.0 — это в любом случае проект: перенос данных, перенастройка процессов, обучение. Пересмотр прав в его рамках обходится дешевле, чем отдельный проект потом, а новая модель сразу работает на чистых данных.
Кроме того, в 3.0 по-другому устроены многие механизмы — процессы, виды документов, настройки. Перенесённые механически группы могут работать не так, как раньше. Если вы ещё выбираете момент перехода, сначала сравните редакции по функциональности и затратам на миграцию.
Шаг 1. Аудит фактических прав
Начинаю с выгрузки фактической картины из действующей базы:
- список пользователей и их групп доступа;
- что каждая группа даёт по видам документов: договоры, счета, акты, внутренние документы;
- заблокированные и уволенные пользователи, у которых остались права.
Параллельно — короткие интервью с руководителями подразделений. Вопросы простые:
- кто в отделе должен видеть все документы отдела, а кто только свои;
- нужен ли смежным подразделениям доступ на просмотр;
- какие документы конфиденциальны и кто вправе их видеть.
На выходе три артефакта: матрица «как есть», список сценариев доступа «как должно быть» и перечень расхождений между ними. Расхождения — это и есть риски, которые видит служба безопасности.
Шаг 2. Проектирование новой модели
Целевую модель описываю матрицей «роль → вид документа → операция»: просмотр, изменение, согласование, удаление. Строится она на нескольких механизмах:
| Механизм | Для чего |
|---|---|
| Профили и группы доступа | Постоянные права по функциональной роли: юрист, бухгалтер, менеджер продаж |
| Разрезы по видам документов, организациям, грифам | Кто видит какие категории документов |
| Рабочая группа документа | Доступ к конкретному документу: автор, ответственный, участники процессов |
| Делегирование | Временная передача прав на время отпуска или командировки |
Ключевая идея — узкие постоянные права и доступ через процесс. Участники процесса согласования включаются в рабочую группу документа и получают доступ именно к нему. Значит, не нужно давать согласующему постоянный доступ ко всем договорам ради одного согласования.
Что важно на этом шаге:
- групп должно быть столько, сколько реальных ролей, а не столько, сколько исторически сложилось;
- у каждой группы — владелец и описание, кому и зачем она нужна;
- конфиденциальные категории документов определяют владельцы процессов и служба безопасности, а не ИТ;
- матрица утверждается письменно — это ТЗ на права доступа.
Шаг 3. Тестирование на сценариях
Модель настраивается в тестовой базе 3.0 и проверяется не абстрактно, а входом под конкретными ролями:
- рядовой менеджер видит только документы своих клиентов;
- руководитель отдела видит документы подразделения, но не чужих отделов;
- сотрудник без постоянного доступа к договорам получает доступ к конкретному договору, когда становится участником согласования;
- бухгалтер видит не только договор, но и приложения к нему, если они нужны для работы.
Последний пункт типичен: на тестировании всегда находятся места, где право закрыто слишком узко и мешает обычной работе. Лучше найти их до запуска, чем в первый день после него.
Шаг 4. Перенос пользователей
Пользователей переношу не «один в один», а по новой матрице: каждому заново назначается роль и группы. Уволенным и заблокированным сотрудникам права не переносятся вовсе.
Даже при хорошем аудите в первую неделю после запуска всплывают индивидуальные исключения, которые не прозвучали на интервью. Закладывайте время на донастройку и назначьте одного ответственного, через которого идут все запросы на дополнительный доступ, — иначе модель начнёт размываться с первого дня.
Шаг 5. Регламент и обучение
Чтобы модель не расползлась снова, нужны:
- инструкция для администраторов: как устроены группы, как выяснить, почему у пользователя есть или нет доступа к документу;
- регламент выдачи прав: кто запрашивает, кто согласует, в какой срок;
- регламент увольнения: блокировка учётной записи и исключение из групп одновременно;
- периодическая ревизия: раз в полгода сверка фактических прав с матрицей;
- короткая памятка пользователям: почему документ может быть не виден и как запросить доступ.
Риски и как их снизить
| Риск | Как снизить |
|---|---|
| Пользователи после запуска не видят нужные документы | Тестирование на реальных сценариях, дежурный администратор в первые недели |
| Новая модель снова обрастает исключениями | Регламент выдачи прав и ревизия раз в полгода |
| Производительность падает из-за сложных ограничений | Проектировать разрезы доступа без избыточной детализации, проверять на объёме реальной базы |
| Конфиденциальные документы доступны лишним людям | Утверждение категорий конфиденциальности владельцами процессов и службой безопасности |
Сроки и стоимость
Объём работ зависит от числа пользователей, подразделений и видов документов, а также от того, насколько запущена текущая модель. Для компании на сотню-две пользователей аудит, проектирование и тестирование прав обычно укладываются в несколько недель и идут параллельно с другими работами по переходу. Для оценки удобно отталкиваться от почасовой ставки — ориентир 2 500 ₽/ч — и перечня подразделений и видов документов.
Пересмотр прав я делаю как часть проекта перехода на 1С:ДО 3.0. Если переход пока не планируется, а с правами уже проблемы, начать можно с аудита 1С: он покажет, кто что видит сейчас и где основные риски.
Права доступа — это не настройка, которую сделали один раз, а процесс. Переход на 3.0 даёт шанс начать его с чистого листа.
Итог
- При переходе на 1С:ДО 3.0 права доступа стоит спроектировать заново, а не переносить старые группы.
- Основа новой модели — аудит фактических прав и утверждённая бизнесом матрица «роль → документ → операция».
- Постоянные права делайте узкими, доступ для согласования выдавайте через рабочую группу документа.
- Проверяйте модель в тестовой базе входом под реальными ролями.
- Закрепите результат регламентами выдачи прав, увольнения и периодической ревизии.
