Ошибки в проектировании групп приводят к тому, что до 30% сотрудников в компаниях среднего бизнеса обладают избыточными правами, что делает SoD (Separation of Duties) критическим барьером против внутреннего фрода. Разделение полномочий — это не просто запрет на совмещение ролей, а жесткая архитектура, где одна транзакция требует участия минимум двух разных групп доступа.
Конфликт ролей: где кроется реальный риск
Главная ошибка администратора — объединение функциональных прав в одной группе «Супер-пользователь» или «Админ отдела». В финансовом контуре это приводит к ситуации, когда один сотрудник может и создать заявку на оплату, и утвердить её. Согласно практике аудитов по стандарту ISO 27001, именно отсутствие SoD в 40% случаев становится причиной успешного внутреннего хищения средств в компаниях с численностью 200–500 человек.
Пример: в отделе закупок пользователь не может состоять одновременно в группах 'Vendor_Management' (создание контрагента) и 'Payment_Approval' (подтверждение платежа). Если бизнес-процесс требует этого от одного человека, внедряется временный доступ через PIM/PAM, а не постоянное членство в группе. Экспертный вывод: любая группа, дающая право на изменение мастер-данных, должна быть изолирована от группы, дающая право на финансовое исполнение.
Матрица несовместимости как фундамент SoD
Проектирование начинается с матрицы несовместимости, где на пересечении двух ролей ставится метка «X» (запрещено). Для организации в 1000 человек такая матрица обычно включает от 15 до 40 критических пересечений. Без этой матрицы Принцип наименьших привилегий (PoLP) при проектировании групп превращается в гадание, так как администратор видит отдельные права, но не видит их опасного сочетания.
Кейс: внедрение матрицы в ритейл-сети сократило количество «токсичных сочетаний» прав с 12% до 0,5% за один цикл аудита (3 месяца). Плюс такого подхода — прозрачность для службы безопасности; минус — трудозатраты на согласование с владельцами бизнес-процессов. Мой вывод: тратить 2 недели на согласование матрицы выгоднее, чем разгребать последствия одного инцидента, стоимость которого в среднем составляет от 500 000 до 3 000 000 рублей для МСБ.
Техническая реализация: статика против динамики
В классическом AD невозможно запретить членство пользователя в двух группах одновременно на уровне схемы. Это решается либо через жесткий регламент и Аудит прав доступа, либо через автоматизацию. Статические группы в этом плане опасны: при ротации кадров сотрудник переходит в новый отдел, получает новые права, но старые группы не удаляются, создавая «наслоение» полномочий.
Сравнение: статический метод требует ручной проверки каждые 30 дней (затраты ~10 человеко-часов на 100 юзеров), динамические группы на основе атрибутов AD (например, Department=Finance AND Role=Approver) исключают ошибку ввода. Однако динамика требует идеального порядка в HR-данных. Экспертный вывод: для критических узлов SoD используйте только статические группы с обязательным ежеквартальным пересмотром через Workflow-систему.
Ловушки вложенности и наследование прав
Самый коварный момент — вложенные группы. Пользователь может не состоять в группе 'Payment_Approval' напрямую, но быть членом группы 'Finance_Leads', которая вложена в группу подтверждения платежей. В итоге SoD нарушается незаметно для администратора, который смотрит только на прямой состав группы. Это типичная дыра в безопасности при использовании Модель AGD (Account, Global, Domain), если иерархия не задокументирована.
Пример: пользователь в группе 'IT_Support' (доступ к серверам) через вложенность попадает в 'Domain_Admins'. Риск возрастает экспоненциально, так как компрометация одной учетной записи дает полный контроль над инфраструктурой. Мой вывод: запретите вложенность групп для всех ролей с уровнем доступа «High» и «Critical». Только плоская структура гарантирует предсказуемость SoD.
Вывод
Для исключения конфликта интересов необходимо внедрить жесткую матрицу несовместимости ролей и полностью отказаться от вложенности групп в критических сегментах сети. Начинать следует с инвентаризации прав по принципу «кто может создать, а кто — утвердить». Избегайте создания «универсальных» групп доступа; лучше создать 10 узкоспециализированных групп, чем одну широкую. Оптимальный выбор для контроля — сочетание статических групп для критических прав и динамических для общекорпоративных, с обязательным аудитом раз в 90 дней.
