Приветствую вас, коллеги!
Неприятный вопрос
Вопрос, который руководителю обычно никто не задает: кто в вашей базе видит зарплату сотрудников?
Не «кто должен видеть», а кто фактически может открыть и посмотреть. Это разные списки, и второй почти всегда длиннее.
Сегодня - как проверить это самому примерно за час, что вы там скорее всего найдете и что с этим делать))
Почему так получается
Сразу скажу: дело обычно не в чьем-то злом умысле и не в том, что кто-то плохо настроил систему.
Дело в том, как права раздаются в реальной жизни. Схема всегда одна и та же:
Человеку нужно сделать задачу. У него не хватает прав. Он идет к тому, кто может дать. Тот пробует дать ровно нужное, не получается с первого раза, времени нет, и в итоге звучит фраза: «да дай ему полные, потом разберемся».
Потом не разбираются. Никогда.
Умножьте это на пять лет, десяток сотрудников и пару смен бухгалтера - и получится текущая картина. Никто не виноват, а ситуация плохая.
И вторая причина, более техническая. Типовые профили в 1С сделаны широкими - чтобы подошли большинству. Профиль «Бухгалтер» из коробки дает больше, чем нужно конкретному вашему бухгалтеру по первичке. Это не ошибка вендора, это компромисс - но компромисс в сторону «пусть лучше будет доступ».
Как устроены права в 1С
Коротко и по-человечески, чтобы вы понимали, что смотрите.
Уровень первый: профили групп доступа. Это наборы разрешенных действий. «Бухгалтер», «Менеджер по продажам», «Кадровик», «Администратор». Профиль отвечает на вопрос что человек может делать.
Уровень второй: группы доступа. Здесь указывается, к каким данным применяется профиль. Например: профиль «Бухгалтер», но только по организации «Ромашка», только по складу номер два.
Уровень третий: ограничение на уровне записей, его еще называют RLS. Это тонкая настройка видимости конкретных строк - по организациям, подразделениям, складам, контрагентам.
Практический вывод из этой конструкции: чтобы человек видел зарплату, достаточно ошибки на любом из трех уровней. Поэтому смотреть надо все три, а не только список пользователей.
Настраивается все это в разделе «Администрирование», в настройках пользователей и прав.
Проверка за час: шесть пунктов
Порядок, в котором я это смотрю на новом объекте.
Первое: полный список пользователей. Просто откройте и прочитайте. Обычно первое открытие уже дает результат: половина фамилий вызывает вопрос «а это кто?».
Второе: у кого административные права. Смотрим, у кого стоит профиль администратора или полные права. Вопрос к каждому: зачем? Нормальная ситуация - один-два человека. Если их пять - это не система прав, это ее отсутствие.
Третье: кто уже не работает. Сверьте список пользователей с текущим штатом. Отдельно проверьте, разрешен ли вход у тех, кто ушел. Это самая частая и самая простая находка.
Четвертое: кто видит кадры и зарплату. Здесь смотрим не только очевидных кадровиков и расчетчиков, но и всех, у кого широкий профиль: администраторы видят все по определению.
Пятое: кто может открывать внешние отчеты и обработки. Про это отдельный раздел ниже, потому что это самый недооцененный пункт из всех.
Шестое: включен ли журнал регистрации и хранится ли он. Он нужен не для слежки, а для ответа на вопрос «кто и когда это сделал», когда вопрос возникнет.
Час - это реальная оценка для компании до тридцати пользователей. Просто прочитать и выписать, без правок.
Пять типичных находок
Что обнаруживается почти всегда. Проверьте, нет ли у вас того же.
Первая: активные учетки уволенных. Человек ушел полгода назад, вход разрешен, пароль тот же. Обычно просто забыли.
Вторая: полные права у того, кому их дали «на время». Временно - самое постоянное слово в администрировании.
Третья: общая учетка. Одна запись, под которой работают трое, потому что так проще. В журнале регистрации потом стоит один и тот же пользователь, и понять, кто именно провел документ, невозможно.
Четвертая: помощник бухгалтера с правами бухгалтера. Профиль взяли готовый, потому что свой настраивать долго. В результате стажер видит расчетные листки всей компании.
Пятая, самая неприятная: доступ у подрядчика, с которым давно не работаете. Учетка внешнего специалиста, заведенная три года назад для разовой задачи. Про нее не помнит уже никто.
И общее наблюдение: ни одна из этих находок не является чьим-то умыслом. Все пять - это накопившаяся неаккуратность. Именно поэтому их и надо периодически вычищать, а не искать виноватых.
Внешние обработки - главная дыра
Пункт, ради которого стоило писать статью.
В 1С есть механизм внешних отчетов и обработок - файлов, которые открываются в базе и делают с данными что угодно. Это штатная и полезная вещь: так делаются разовые выгрузки, исправления, специфические отчеты.
И вот в чем проблема. Право открывать внешние обработки фактически обходит всю вашу тонкую настройку прав. Человек, который может открыть произвольный файл обработки, может через него получить данные, к которым в интерфейсе доступа не имеет.
Называется это право «Интерактивное открытие внешних отчетов и обработок» - искать по этому имени, оно же будет и в профилях групп доступа. И вот вам косвенное подтверждение, что дело серьезное: при выдаче этой роли 1С сама показывает предупреждение безопасности. Вендор знает, что раздает, и предупреждает - просто предупреждение это обычно проматывают.
Что это значит практически: вы можете сколько угодно настраивать видимость зарплаты по профилям, но если у пяти человек есть право открывать внешние обработки, настройка стоит немного.
Что с этим делать:
- право открывать внешние обработки должно быть у единиц. В идеале - только у администратора и у вашего подрядчика;
- нужные регулярно обработки подключаются в базу как дополнительные и раздаются по правам штатно, а не открываются файлом каждый раз;
- и обязательно проверьте, что лежит в дополнительных обработках прямо сейчас. Иногда там обнаруживаются занятные вещи, добавленные годы назад.
Это, пожалуй, единственный пункт из всей статьи, который я бы попросил проверить сегодня, даже если остальное отложите.
Уволенные, которые все еще в системе
Короткий, но важный раздел - и он перекликается с тем, что я писал про уход администратора.
Учетную запись уволенного надо отключать, а не удалять.
Причина та же: на пользователя завязаны документы, история изменений, иногда регламентные задания. Удалив запись, вы усложните себе разбор истории, а иногда и сломаете работающее.
Правильно так: снять разрешение на вход, убрать из групп доступа, оставить саму запись. Данные остаются связанными, доступ закрыт.
И организационный момент. Отключение учетки должно быть пунктом в процедуре увольнения - рядом с пропуском и ключами. Если такой процедуры нет, ее стоит написать: это лист бумаги, который экономит много нервов.
Ограничение на уровне записей: мощно, но не бесплатно
Раз уж зашла речь о тонкой настройке, скажу и об оборотной стороне.
Ограничение на уровне записей - вещь мощная. Оно позволяет показать человеку только его склад, только его организацию, только его подразделение. Именно им решается большинство задач вида «пусть видит свое и не видит чужое».
Но за это платят скоростью. Механизм добавляет проверки к каждому запросу к базе, и на больших объемах это заметно. Я писал отдельно про то, почему 1С начинает тормозить, - плохо настроенные ограничения на уровне записей регулярно оказываются среди причин.
Мой практический подход: сначала навести порядок в профилях и группах доступа - это бесплатно по производительности. И только если этого не хватает для решения задачи, включать ограничения на уровне записей, и настраивать их аккуратно, а не «на всякий случай везде».
Тонкая настройка прав там, где хватило бы здравого смысла, - частая причина медленной базы.
Чего делать не надо
Короткий список ошибок, которые делают сразу после того, как прочитают такую статью.
Не урезайте все разом в четверг вечером. Люди придут в пятницу и не смогут работать, а вы будете разбираться в авральном режиме. Правки делаются по одной, с проверкой.
Не начинайте с поиска виноватых. Права раздавал не злодей, а человек, у которого горела задача. Поиск виноватых гарантирует, что в следующий раз вам просто не скажут о проблеме.
Не делайте вид, что настройка прав - разовая работа. Люди приходят и уходят, задачи меняются. Раз в полгода надо перечитывать список - это полчаса.
И не путайте права с доверием. Ограничение доступа - это не заявление о том, что человеку не доверяют. Это про то, что данные не должны утекать случайно, а ответственность должна быть персональной. Если это объяснить людям прямо, вопросов обычно не возникает.
Случай из практики
История типовая, и в том или ином виде повторяется почти на каждом новом объекте.
Компания, оптовая торговля, около двадцати пяти пользователей в базе. Пришли по другому поводу - разбирались с медленной работой. Заодно посмотрели права, потому что ограничения на уровне записей были в списке подозреваемых.
Что нашли в списке пользователей. Всего записей - тридцать четыре при двадцати пяти работающих. Из девяти лишних: четверо уволенных с разрешенным входом, две общие учетки на отдел продаж, одна учетка подрядчика, который делал сайт три года назад, и две с фамилиями, которых никто не смог опознать вообще.
Полные права стояли у четверых: у директора, у главного бухгалтера, у бывшего админа и у менеджера, которому их дали на время инвентаризации два года назад.
Право открывать внешние обработки было у одиннадцати человек. Не потому что кто-то так решил, а потому что оно входило в широкий профиль, который раздали большинству.
Что делали: сначала отключили все лишние учетки - это заняло полчаса и не затронуло никого из работающих. Потом сузили круг с полными правами до двоих. Потом разобрались с внешними обработками: оставили право у администратора, а две регулярно нужные обработки подключили в базу штатно.
А дальше выяснилось приятное. Ограничения на уровне записей действительно были настроены избыточно - через них крутились проверки, которые давно потеряли смысл. После чистки отчеты стали считаться заметно быстрее.
Вывод, который я из этого делаю: порядок в правах - это не только про безопасность. Он часто оказывается и про скорость, потому что лишние ограничения стоят процессорного времени на каждом запросе.
Чек-лист
Распечатайте и пройдите по пунктам. Час времени.
- Открыть список пользователей и вычеркнуть всех, кто не работает.
- Проверить, у кого административные права. Оставить минимум.
- Найти общие учетки и заменить их персональными.
- Посмотреть, кто видит кадры и зарплату - и сверить со списком тех, кто должен.
- Проверить право на внешние обработки. Это главный пункт.
- Посмотреть, что лежит в дополнительных обработках.
- Убедиться, что журнал регистрации ведется и хранится хотя бы несколько месяцев.
- Добавить отключение учетки в процедуру увольнения, если ее там нет.
И назначьте дату следующей проверки - через полгода. Без этого список снова расползется, причем ровно тем же способом.
Если делать некому
Как вы помните, я айти-специалист: веду 1С для организаций, собираю и держу серверы. У нас команда из десяти программистов, и разбор прав доступа - одна из первых вещей, которые мы делаем, когда берем новую базу на сопровождение.
Чем помогаем:
- проводим аудит прав - кто что видит и кто чем может воспользоваться, в виде понятного списка;
- чистим лишние учетки и разбираемся с общими;
- настраиваем профили под ваши реальные роли, а не берем типовые как есть;
- закрываем внешние обработки и подключаем нужные штатно;
- настраиваем ограничения по организациям и складам там, где это действительно нужно - и убираем там, где они только тормозят;
- берем 1С на сопровождение, чтобы список пользователей не расползался снова.
Подробнее про обслуживание: 1c.akernel.ru/services/it-podderzhka
И одно бесплатное предложение. Если хотите быстро понять масштаб - посмотрите сами два числа: сколько всего пользователей в базе и сколько человек у вас работает. Разница между ними и есть первая оценка. Напишите эти два числа, и я скажу, много это или нормально для вашего размера)
Читайте также: Уволился системный администратор. Первые 48 часов, 1С тормозит: диагностика за 30 минут, Фишинг для бухгалтеров и Ваш бэкап 1С точно рабочий?.
Названия профилей и разделов приведены для типовых конфигураций - в вашей они могут отличаться.
Комментарии
Комментариев пока нет. Будьте первым!