С каждым годом защита данных становится все более актуальной темой в нашей жизни.

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

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

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

И для начала вспомним механику присвоения прав доступа в 1С:ERP. Полномочия на чтение или изменение того или иного объекта метаданных пользователем определяется ролями, перечень которых объединяется в профиль доступа. К профилю доступа создается группа доступа, которая является перечнем пользователей, которым присвоены полномочия профиля доступа.

Рис. 1. Профиль и группа доступа.

Дополнительно в 1С:ERP предусмотрена опциональная возможность создания групп пользователей, которые по своей сути являются элементом иерархии справочника пользователей, но при этом позволяет присваивать нескольким пользователям, в том числе и новым, одинаковые полномочия.

Рис. 2. Группы пользователей и присвоение им прав доступа.

Теперь же мы можем перейти к основной теме статьи – принципам разграничения полномочий в 1С:ERP. Рассмотрим несколько механизмов, позволяющих разделить права доступа пользователей.

Разработка ролевой модели и матрицы полномочий.

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

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

Использование принципа наименьшего доступа.

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

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

Отказ от типовых профилей доступа.

Типовая конфигурация 1С:ERP предлагает довольно много преднастроенных профилей доступа для основных функциональных областей среднестатистического предприятия. Однако при детальном анализе этих профилей можно сделать вывод об избыточности прав доступа в некоторых из них. И за это невозможно упрекнуть разработчиков фирмы 1С – крайне сложно подогнать «под одну гребенку» функционал условного менеджера по продажам для разных отраслей экономики.  Поэтому разработка индивидуальных профилей доступа под конкретные задачи с учетом специфики деятельности конкретной организации позволяет настроить полномочия пользователей более точно и избежать ненужных доступов.

Ведение заявок.

Заявки на выбытие различных ресурсов, будь то денежные средства или товарно-материальные ценности (ТМЦ), играют ключевую роль в управлении активами компании. Они позволяют точно отслеживать движение ресурсов, что, в свою очередь, помогает избежать несогласованных или излишних расходов.

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

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

Централизованное ведение справочников.

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

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

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

Еще более эффективным является ведение НСИ в отдельной мастер-базе с ограниченным доступом (в том числе и отдельные MDM-решения), а также реализация заявок на изменение НСИ.

Анализ SoD-рисков.

SoD-риск (Segregation of Duties, разделение прав доступа) – это риск совмещение пользователем прав доступа, позволяющих ему умышленно или неумышленно исказить данные в учетной системе. Простыми словами SoD-риск возникает, когда набор прав доступа пользователя позволяет ему либо допустить критичную ошибку, либо совершить какие-либо действия из корыстного/злого умысла.

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

Или можно в качестве еще одного примера привести самый классический SoD-риск: пользователь имеет доступ на создание заявки на списание ТМЦ и доступ на ее согласование. В итоге сам заявку создал, сам согласовал. Результат предсказуем.

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

RLS.

RLS (record level security) – механизм ограничения доступа на уровне записей в 1С. Данный механизм позволяет максимально гибко настраивать права доступа к объектам метаданных для каждого пользователя, что на практике позволяет решить главную проблему в настройке прав доступа – «как сделать, чтобы пользователь видел только те документы, которые к нему относятся». Ведь действительно другие типовые инструменты 1С:ERP не позволяют ограничить видимость части документов в журнале. Если у пользователя есть права на чтение документа, то он увидит весь журнал со всеми документами. А в реальной эксплуатации очень часть возникает ситуация, когда пользователь должен редактировать какой-то документ, но только «свой» (свое подразделение, своя организация, свой склад и пр.), а «чужие» редактировать не должен иметь возможность. И для решения этой задачи и используют RLS.

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

Заключение.

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