Ситуация 4. Конфликт через наследование: право пришло вместе с должностью.

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

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

И в этот момент все, кто занимает эту должность, получили конфликт. Одним изменением. Без единой заявки. Без участия руководителя. Тихо.

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

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

Такой список читается совсем иначе, чем одиночный конфликт. Когда в документе двадцать человек с одной и той же парой групп, вывод очевиден: править надо не двадцать сотрудников, а правило автоназначения. Меняешь набор для должности — и двадцать конфликтов закрываются одним действием.

Здесь и проявляется польза от того, что конфликты попадают в документ, а не в предупреждение на экране. Одиночное предупреждение показывает симптом. Список показывает причину.

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

Ситуация 5. Исключение: конфликт признан допустимым и это оформлено.

Самая честная ситуация из всех. Есть конфликты, которые устранить нельзя.

Филиал на пятнадцать человек. Бухгалтер один. Он заводит контрагентов, он же готовит платежи, он же сверяет выписки. Второго бухгалтера не будет — экономически бессмысленно. Разделить полномочия физически невозможно: делить не с кем.

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

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

Правильный путь — исключение. Конфликт признается допустимым осознанно, с причиной и с ответственным.

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

Что это дает на практике.

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

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

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

Исключения полезно пересматривать. Филиал вырос, взяли второго бухгалтера — основание для исключения исчезло, полномочия можно разделить по-настоящему. Без реестра исключений об этом никто не вспомнит, потому что вспоминать будет не о чем.

Ситуация 6. SoD при пересмотре доступов: аттестация показывает не только «кому», но и «где конфликт».

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

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

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

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

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

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

Что важно контролировать:

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

2.     Гранулярность правил. Для каждой пары нужно решить осознанно: конфликт создает группа целиком или достаточно отдельного полномочия из ее состава. Слишком грубое правило будет мешать работе и его отключат. Слишком узкое пропустит риск.

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

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

5.     Скорость разбора выявленных конфликтов. Документ с конфликтами, который лежит без решений три месяца, хуже, чем его отсутствие: он создает иллюзию контроля. У разбора должны быть ответственные и срок.

6.     Обоснованность исключений и их пересмотр. Каждое исключение должно иметь причину и компенсирующие меры. И каждое должно периодически проверяться на актуальность — обстоятельства меняются, а исключение живет вечно, если его никто не трогает.

7.     Сроки временных доступов. Любая выдача «на подмену» без даты окончания рано или поздно станет постоянным конфликтом. Срок должен ставиться в момент выдачи, а не вспоминаться потом.

Зачем это бизнесу и службе ИБ:

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

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

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

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

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

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

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

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

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