Ошибки в правах доступа к 1С могут стоить УК денег, времени и доверия жителей. Разбираем ключевые риски и как выстроить безопасную систему
Фаррух Дадобоев
Генеральный директор Эксперт по автоматизации УК
Права доступа в 1С часто считают технической темой и передают системному администратору или специалисту по сопровождению.
На практике это вопрос управления компанией. Именно директор должен понимать, кто видит данные жителей, кто меняет начисления, кто работает с оплатами и кто может корректировать настройки учета.
В 1С собраны данные, от которых зависит работа УК. Это лицевые счета, собственники, начисления, показания, оплаты, задолженность, договоры и бухгалтерские документы. В некоторых базах также ведут кадровый учет и зарплату.
Лишняя роль может открыть сотруднику ненужный раздел. Общая учетная запись мешает установить автора изменения. Неснятое право бывшего сотрудника создает риск после увольнения.
Поэтому контроль доступа нельзя сводить к паролю на входе. Пароль отвечает только на вопрос: «Кто вошел в программу?» Система прав должна отвечать еще на три вопроса:
какие данные сотрудник может видеть;
какие действия он может выполнять;
какие операции можно связать именно с ним.
Правильная настройка дает простой результат. Каждый сотрудник получает доступ только к тем данным и операциям, которые нужны для его обязанностей. Не больше и не меньше.
Почему для УК цена ошибки особенно высока
В ЖКХ одна ошибка может повлиять сразу на сотни или тысячи лицевых счетов.
Представим типовую ситуацию. Сотрудник меняет параметр услуги для одного случая. Но настройка действует для дома или группы домов. Ошибка попадает в массовое начисление. Компания получает обращения жителей, перерасчеты и дополнительную нагрузку на расчетный отдел.
Есть и другой сценарий. Пользователь случайно меняет договор, получателя платежа или реквизиты. Если права не разделены, такую ошибку может допустить сотрудник, который не отвечает за этот участок.
Третий сценарий связан с персональными данными. Для работы диспетчеру может быть нужен адрес, номер телефона и история заявки. Это не означает, что ему нужен полный доступ к данным собственника, истории начислений, оплатам и всем документам лицевого счета.
Главная проблема здесь не в недоверии к людям. Большинство ошибок возникает из-за лишней возможности совершить действие. Человек не заметил отбор, выбрал не тот период или применил операцию к большему числу объектов.
Хорошая система доступа снижает саму вероятность такого события.
Три риска, которые должен видеть директор
1. Операционные ошибки
Сотрудник получает больше прав, чем требует его функция. Он может менять тарифы, выполнять перерасчеты, редактировать оплаты или затрагивать закрытый период. Иногда такие права выдаются «на всякий случай». Иногда они остаются после временной замены коллеги.
В результате границы ответственности становятся размытыми. Расчетчик может вмешаться в бухгалтерский участок. Диспетчер видит финансовые данные, которые не нужны для регистрации заявок. Чем шире доступ, тем больше зона возможной ошибки.
2. Неправомерные действия
Доверие важно. Но оно не заменяет внутренний контроль. Если один пользователь может создать документ, изменить его и провести операцию, компания зависит от одного человека. Если несколько сотрудников работают под общей учетной записью, установить автора действия трудно.
Разделение прав защищает не только компанию. Оно защищает и сотрудника. Когда действия выполняются под персональной учетной записью, добросовестному работнику проще подтвердить, что он не вносил спорное изменение.
3. Отсутствие прослеживаемости
После ошибки директору важны точные ответы. Кто изменил данные? Когда это произошло? Почему операция была ему доступна? При общем логине журнал покажет учетную запись, но не конкретного человека.
Без прослеживаемости разбор инцидента превращается в опрос сотрудников. Время уходит, расчеты приходится перепроверять, а причина может остаться неизвестной. Компания исправляет последствия, но не устраняет источник проблемы.
Персональные данные: доступ должен быть обоснован работой
Управляющая компания работает с персональными данными жителей и сотрудников. Федеральный закон 152-ФЗ требует принимать правовые, организационные и технические меры для защиты таких данных от неправомерного или случайного доступа, изменения, копирования и других неправомерных действий.
Это означает, что одного приказа о конфиденциальности недостаточно. Доступ в самой информационной системе должен соответствовать трудовым обязанностям.
Руководителю полезно задать простой вопрос: сможет ли компания объяснить, зачем конкретному сотруднику открыт каждый доступный ему раздел?
Если ответ звучит как «так было настроено», «у всех одинаково» или «вдруг понадобится», права нужно пересмотреть.
Слишком жесткие ограничения тоже мешают работе. Сотрудник начинает передавать документы коллегам или хранить данные вне системы. Поэтому задача состоит не в максимальном запрете. Права должны точно соответствовать рабочему процессу.
Семь признаков слабой системы доступа
Слабую систему доступа можно узнать по семи признакам:
У большинства пользователей есть полные или почти полные права.
Несколько человек входят под одним логином.
Права нового сотрудника копируют у коллеги без анализа задач.
Временный доступ после замещения не отзывают.
Внешнему специалисту открывают всю базу на неопределенный срок.
Запись уволенного или переведенного сотрудника остается активной.
Выданные права никто регулярно не проверяет.
Если в компании есть хотя бы два таких признака, доступами уже нужно заниматься как отдельным управленческим процессом.
Как выглядит правильное разделение прав
В основе должна быть не должность, а функция. Две управляющие компании могут использовать одинаковые названия должностей, но распределять обязанности по-разному.
Поэтому сначала нужно описать процесс. Какие данные нужны сотруднику? Что он должен с ними делать? По каким организациям, домам и участкам он работает? Нужен ли ему просмотр, создание, изменение или удаление?
После этого формируют профили и группы доступа. Платформа 1С позволяет разделять права на чтение, добавление, изменение и удаление. Можно применять ограничения на уровне записей и полей. Например, открыть данные только по определенной организации. Точные возможности зависят от конфигурации и ее версии.
Практическая модель для УК может выглядеть так.
Руководитель
Директору нужны отчеты, показатели, задолженность и движение денежных средств. Ему не всегда нужно право менять первичные данные. Руководитель должен видеть картину, но не обязан работать в режиме администратора.
Главный бухгалтер
Главному бухгалтеру нужны бухгалтерские операции, отчетность и контроль закрытия периода. Доступ к расчетному блоку зависит от принятой модели работы. Изменение прав пользователей лучше отделить от бухгалтерской функции.
Бухгалтер
Бухгалтеру открывают его участок: банк, кассу, расчеты с поставщиками или отдельную организацию. Доступ ко всем операциям и юридическим лицам обычно не нужен.
Специалист по начислениям
Расчетчику нужны лицевые счета, показания, начисления, перерасчеты и платежные документы. Ему не всегда нужны права на изменение банковских реквизитов, учетной политики или кадровых данных. Массовые операции и перерасчеты за прошлые периоды требуют отдельного контроля.
Специалист паспортного стола
Ему нужны сведения о помещениях, проживающих и регистрационном учете. Финансовые документы, зарплата и технические настройки не относятся к этому участку.
Диспетчер
Диспетчеру нужны заявки, контакты для связи, адрес и информация, необходимая для выполнения обращения. Возможность менять начисления, оплаты или договоры ему не нужна.
Юрист
Юристу нужны данные о задолженности, договоры и документы для претензионной работы. Право редактировать исходные начисления обычно не связано с его функцией.
Системный администратор и специалист по 1С
Техническому специалисту может быть нужен административный доступ. Его выдают на персональную учетную запись и используют по регламенту. Для подрядчика создают отдельную запись. Срок доступа и задачу определяют заранее. После работ доступ закрывают.
Это отправная точка. Итоговая матрица зависит от структуры УК, числа баз, состава модулей и внутренних регламентов.
Какие операции нельзя оставлять без отдельного контроля
Не все действия в 1С одинаковы по уровню риска. Руководителю стоит выделить критичные операции и установить для них особый порядок.
К ним относятся:
изменение тарифов, услуг и формул расчета;
массовое начисление и массовый перерасчет;
корректировка данных за закрытые периоды;
изменение получателей платежей и банковских реквизитов;
ручная корректировка оплат и задолженности;
удаление документов и объектов учета;
изменение настроек обмена с банками, ГИС ЖКХ и другими системами;
выгрузка больших массивов данных;
создание пользователей и изменение их прав;отключение контроля или изменение технических настроек.
Для части операций достаточно ограничить круг исполнителей. Для более чувствительных действий полезен принцип двух участников. Один сотрудник готовит изменение, другой проверяет его до применения.
Если согласования в программе нет, можно начать с простого регламента. Основание фиксируют в заявке. Ответственный проверяет параметры. Контроль должен быть пропорционален риску. Перерасчет по одному счету и массовое изменение по десяти домам требуют разной проверки.
Почему интерфейс не равен ограничению прав
Иногда руководитель видит у сотрудника короткое меню и считает, что доступ настроен. Но скрытая команда и запрещенная операция — не одно и то же.
Интерфейс отвечает за удобство. Права отвечают за возможность прочитать или изменить данные. Нужно убедиться, что пользователь не откроет запрещенные сведения через отчет, связанную форму или обработку. Проверку проводят под тестовой записью с тем же набором прав.
Особое внимание нужно уделить выгрузкам. Иногда сотрудник не может изменить данные, но может сформировать отчет и сохранить большой массив сведений. Для компании это отдельный риск.
Журнал регистрации помогает, но не заменяет ограничения
Журнал регистрации позволяет анализировать события в программе и действия пользователей. Но он приносит пользу только при трех условиях.
Первое — у каждого сотрудника есть персональная учетная запись.
Второе — регистрация нужных событий настроена и данные хранятся достаточный срок.
Третье — в компании определено, кто и в каких случаях анализирует журнал.
Журнал не предотвращает ошибку. Он помогает восстановить картину после события. Поэтому сначала ограничивают лишние действия, затем фиксируют значимые события и регулярно их контролируют.
Как внедрить контроль доступа без остановки работы
Начинать нужно не с удаления прав. Резкое ограничение может остановить начисления, закрытие месяца или обмен данными.
Я рекомендую последовательный подход.
Шаг 1. Провести инвентаризацию
Нужно получить список действующих сотрудников, бывших работников, подрядчиков, технических и общих записей. По каждой записи фиксируют владельца, роль, последнее использование и выданные права.
Шаг 2. Описать рабочие функции
Для каждой должности определяют ежедневные, периодические и временные задачи. Редкая операция не должна становиться причиной широких постоянных прав.
Шаг 3. Составить матрицу доступа
В строках указывают роли. В столбцах — данные и действия. Для каждой ячейки выбирают вариант: нет доступа, просмотр, создание, изменение, удаление или специальная операция. Отдельно фиксируют ограничения по организациям и домам.
Шаг 4. Выделить критичные операции
Для них назначают владельца, исполнителя и проверяющего. Также определяют документ-основание и способ фиксации результата.
Шаг 5. Настроить и протестировать
Изменения проверяют на копии базы или в согласованное время. Нужно убедиться, что сотрудник выполняет всю работу без обходных действий.
Шаг 6. Ввести порядок выдачи и отзыва прав
Новый доступ выдают по согласованной заявке. Временные полномочия получают дату окончания. При переводе сотрудника права пересматривают. При увольнении учетную запись блокируют в установленный срок.
У процесса должен быть владелец. Техническую настройку может вести администратор. Бизнес-доступ согласует руководитель соответствующего направления.
Шаг 7. Проводить регулярный пересмотр
Права нужно сверять с обязанностями. Для многих УК разумной отправной точкой будет ежеквартальная проверка. Внеплановый пересмотр нужен после кадровых изменений, подключения нового блока или перераспределения домов.
Что проверить директору уже сейчас
Необязательно начинать с большого проекта. За одну рабочую встречу можно получить первое представление о состоянии доступа.
Попросите ответственных показать:
Полный список пользователей 1С.
Список учетных записей с полными правами.
Общие логины, которыми пользуются несколько человек.
Активные записи бывших сотрудников.
Доступы внешних подрядчиков.
Пользователей, которые могут менять права другим.
Пользователей, которые меняют тарифы, начисления, оплаты и задолженность.
Возможности массовой выгрузки данных.
Порядок выдачи временных прав и блокировки доступа при увольнении.
Настройки журнала регистрации и дату последнего пересмотра прав.
Если на часть вопросов нет ответа, это не повод искать виноватого. Это точка начала работы.
А если УК небольшая
Размер штата не отменяет разделение обязанностей. Один сотрудник может совмещать несколько функций. Значит, его рабочие права будут шире. Но общей учетной записи, бессрочного доступа подрядчиков и постоянной работы с полными правами быть не должно.
Правильный контроль почти незаметен. Расчетчик выполняет начисления. Диспетчер видит нужные контакты. Бухгалтер работает со своим участком. Руководитель получает отчеты. Подрядчик подключается только на время задачи. Существенное действие можно связать с конкретной учетной записью.
За годы работы с управляющими компаниями я убедился: устойчивость учета зависит не только от функций программы. Она зависит и от того, насколько точно система отражает полномочия людей. Если любой пользователь может изменить критичные данные, автоматизация остается уязвимой.
Разделение прав — это не недоверие к коллективу. Это защита сотрудников, жителей и самой УК. Она снижает вероятность ошибки, затрудняет неправомерные действия и помогает установить причину проблемы.
Главный принцип прост: сотрудник должен видеть и менять только то, что необходимо ему для работы. Критичные действия должны быть ограничены и проверяемы. Каждая учетная запись должна принадлежать конкретному человеку.
Если вы не уверены, как распределены права, начните с аудита. Сопоставьте пользователей, обязанности и операции. Проверьте общие логины, полные права и учетные записи подрядчиков. Отдельно оцените доступ к начислениям, оплатам и персональным данным.
Такая проверка часто занимает меньше времени, чем исправление одной массовой ошибки. А ее результатом становится не только более безопасная 1С. Компания получает прозрачную систему ответственности.