Автор текста: Наталья Хизбулина

Консультант департамента 1С «КОРУС Консалтинг»

Представьте: вы долго и напряженно внедряли вашу ИТ-систему и наконец запускаете ее в эксплуатацию. Но вместо радости от успешного старта, пользователи сталкиваются с проблемами из-за неправильно настроенных прав доступа. Бывало такое? Надеюсь, что нет, ведь это не просто неудобства — это серьезные риски для бизнеса: утечки данных, нарушения безопасности, остановки процессов.
Сегодня хочу поделиться с вами рекомендациями, как избежать подобных ошибок и обеспечить безопасность данных с помощью разработки матрицы прав доступа. 

Почему настройка прав доступа важна с самого начала проекта

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

Почему важно качественно настроить права доступа

Настройка прав доступа или разработка ролевой модели — обязательное условие для успешного внедрения новой системы на базе 1С. Эта задача стоит как перед проектной командой, так и заказчиком, вне зависимости от типа решения, количества бизнес-процессов и пользователей. 

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

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

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

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

Основные риски на проектах, связанные с правами доступа

Некорректно настроенные права доступа при внедрении системы 1С могут привести к сбоям, создать угрозы безопасности и остановки процессов. Рассмотрим основные риски и чем они чреваты для компании:

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

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

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

4. Заказчик не участвует в процессе согласования матриц прав доступа по процессам. Очень важно, чтобы сотрудники заказчика участвовали в согласовании прав и вместе с проектной командой определяли, какой профиль группы доступа в системе соответствует функциональной роли сотрудника. Иначе у ИТ-службы компании могут возникнуть сложности с настройкой групп и правильным распределением пользователей по этим группам.

5. Отсутствие регламента для разработки прав доступа. Без четко прописанных регламентов по созданию прав доступа для новых объектов системы разработчики могут не учитывать эти риски, что тоже приведет к ошибкам в будущем.

Как настроить права доступа и обеспечить безопасный запуск

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

Шаг №1. Включите подготовку прав доступа в этап обследования или сбора требований

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

Шаг №2. Интегрируйте подготовку матрицы в каждый процесс

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

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

Шаг №3. Проведите интеграционное тестирование с настроенными правами доступа

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

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

Шаг №4. Разработайте регламент создания ролей на новые объекты конфигурации 

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

Шаг №5. Учитывайте, что матрица прав доступа будет меняться

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

Шаг №6. Вовлекайте заказчика с самого начала

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

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

*Рекомендация от «бывалого»

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

Tech IT Easy — телеграм-канал о карьере в ИТ от экспертов КОРУСа