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

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

Проблема не в том, что этот человек обязательно что-то украдет. Проблема в том, что если он украдет — этого никто не заметит. Не потому что плохой контроль, а потому что контроль устроен как проверка чужой работы. А здесь чужой работы нет: и заведение, и оплата — это работа одного и того же человека. Проверять себя он будет ровно так, как ему удобно.

Разделение полномочий (Segregation of Duties, SoD) — это как раз про такие ситуации. Идея простая: ни один человек не должен контролировать критичный процесс целиком, от начала до конца. Кто заводит поставщика — не платит. Кто согласует закупку — не принимает товар. Кто меняет справочник цен — не оформляет скидки. Разделение не решает проблему нелояльного сотрудника, но делает так, что для нанесения ущерба нужен сговор минимум двух людей. А сговор — это уже совсем другой уровень риска и совсем другая вероятность.

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

Ситуация 1. Классический конфликт: создал поставщика и сам его оплатил.

Классический случай, который при этом продолжает встречаться в живых системах. У сотрудника есть группа доступа, которая разрешает создавать и редактировать карточки контрагентов. И есть вторая группа, которая позволяет формировать и отправлять платежные поручения.

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

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

В 1IDM для этого настраиваются правила Несовместимых прав. Правило описывает пару конфликтующих групп: левая часть и правая часть. Как только правило заведено, система начинает считать это сочетание недопустимым и вмешивается в момент запроса прав. Сотрудник или его руководитель открывает заявку, выбирает группу «Платежи», система видит, что у сотрудника уже есть «Контрагенты: создание и изменение», и просто не дает отправить заявку на согласование. Не помечает желтым, не пишет предупреждение мелким шрифтом — блокирует отправку.

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

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

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

Ситуация 2. Косвенный конфликт: права пришли по частям и сложились в целое.

Здесь все гораздо неприятнее, потому что никто ничего не нарушал.

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

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

Такие накопленные конфликты — основная масса реальных нарушений SoD. Они не появляются одной заявкой. Они складываются из переводов, совмещений, временных поручений, проектных доступов и незакрытых хвостов.

1IDM смотрит не на заявки, а на итоговый набор прав сотрудника. Правило SoD применяется к тому, что у человека есть на руках сейчас — независимо от того, сколькими заявками, когда и кем это выдавалось. Пришло право из роли отдела закупок, а второе — из роли финансового отдела? Для правила это одно и то же: у сотрудника одновременно есть левая и правая часть конфликта.

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

Задание запускается по расписанию и проводит аудит: проходит по всем сотрудникам, сопоставляет их фактические права с матрицей правил SoD и вычисляет конфликты. Результат публикуется в документ — не в лог, который никто не читает, а в документ, с которым дальше работают люди.

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

Именно на этом шаге история с переведенным сотрудником закрывается сама. Приходит документ, ответственный видит, что человек полгода назад ушел из закупок, и снимает закупочную группу. Занимает это минуту. Без регламентного аудита оно висело бы до внешней проверки.

Ситуация 3. Временный доступ «на подмену», который забыли забрать.

Отпуски, больничные, декреты, командировки, увольнения без замены. Подмена — самая частая причина, по которой SoD осознанно нарушают. И самая частая причина, по которой он остается нарушенным.

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

В этот момент SoD-конфликт создается сознательно, и это нормальное управленческое решение: риск простоя выше риска мошенничества на две недели. Ненормально другое — что через две недели никто не вспоминает про откат.

Причин две. Первая: заявка на выдачу есть, а заявки на снятие нет — снятие никому не поручено. Вторая: человек, который отдавал права, сам был «на подхвате» и уже забыл детали.

1IDM решает это через срок. Временный доступ выдается с датой окончания, и система следит за этой датой сама. Наступил срок — права уходят. Не по напоминанию руководителю, не по чек-листу администратора, а автоматически. Вернулся основной сотрудник раньше — доступ отзывается досрочно, руками, но это уже осознанное действие, а не единственная надежда на порядок.

Как только временные права ушли, конфликт исчезает. И это видно в следующем прогоне регламентного аудита: сотрудник, который в прошлый раз попал в документ с конфликтом, в этот раз в нем отсутствует. Ответственному не нужно верить на слово, что «мы там все убрали» — он видит результат в отчёте.

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

Отдельно стоит сказать про исключения на срок. Если подмена длинная — например, сотрудник в декрете и его функции полтора года выполняет коллега, — конфликт неизбежен, и делать вид, что его нет, бессмысленно. Тогда его фиксируют как исключение с понятной причиной. Разница между «конфликт есть, но мы про него знаем, и он оформлен» и «конфликт есть, и никто про него не знает» — это разница между управляемым риском и дырой в безопасности.