Объясните, каким образом разделение обязанностей уменьшает риск злоупотребления привилегированной операцией.
Разделение обязанностей не позволяет одному субъекту единолично выполнить весь критичный процесс: инициировать действие, одобрить его и получить результат. Поэтому компрометация одной учётной записи или злонамеренное действие одного сотрудника не сразу превращается в успешную атаку.
Защита возникает только тогда, когда роли действительно разделены технически, а не просто описаны в регламенте. Контроли должны учитывать независимость участников, область их полномочий и невозможность обойти проверку через альтернативный путь.
Подход возник как часть внутреннего контроля в организациях, где один человек не должен был единолично распоряжаться ценностями, подтверждать операцию и скрывать её последствия. Изначальная проблема состояла в том, что единственная точка контроля позволяла незаметно совершить злоупотребление или подделать подтверждение.
В информационных системах этот принцип перенесли на управление привилегированными действиями: выпуск изменений, финансовые операции, выдачу доступа, работу с ключами и удаление данных. Он дополняет аутентификацию и авторизацию, поскольку проверяет не только «имеет ли субъект право», но и «достаточно ли одного субъекта для этой операции».
Если один оператор может создать привилегированную операцию, самостоятельно её одобрить и выполнить, компрометация его учётной записи даёт злоумышленнику полный путь до результата. Та же архитектура позволяет инсайдеру скрыть злоупотребление, особенно если он контролирует журналирование или выбирает момент выполнения.
Обычная проверка роли не всегда решает проблему. Пользователь может иметь законное право на каждое отдельное действие, но опасный эффект появляется из-за их комбинации: например, создание нового администратора вместе с изменением правил аудита.
Сначала критичную операцию разбивают на независимые этапы и определяют, какие полномочия должны принадлежать разным субъектам. Например, один субъект формирует запрос, другой одобряет его, а отдельный автоматизированный компонент выполняет уже одобренную операцию.
Система должна связывать одобрение с конкретными параметрами операции: объектом, областью действия, сроком и версией запроса. Нельзя считать одобрение универсальным разрешением, которое затем можно применить к изменённым данным. Перед выполнением нужно повторно проверить, что одобренные параметры не изменились и что одобрение ещё действительно.
Независимость контроля означает не только разные роли, но и разные границы доверия. Если один администратор может изменить собственную роль, отключить обязательное одобрение и выполнить операцию, разделение существует лишь номинально. Поэтому правила контроля должны храниться и проверяться компонентом, который не подчинён инициатору операции.
Важно обеспечить неподменяемый аудит: фиксировать инициатора, одобрителя, параметры, время, результат и причину отказа. Журнал сам по себе не предотвращает действие, но помогает обнаружить обход и доказать, кто участвовал в процессе.
У подхода есть компромиссы. Дополнительный участник увеличивает задержку и операционные расходы, а недоступность одобрителя может остановить законную работу. Для срочных случаев применяют ограниченный аварийный режим с коротким сроком действия, усиленной аутентификацией и обязательным последующим разбором; такой режим не должен становиться обычным способом обхода.
Разделение обязанностей также не защищает от сговора участников, захвата нескольких учётных записей или ошибок в самой политике. Оно снижает вероятность и скрытность злоупотребления, но должно сочетаться с минимальными привилегиями, контролем изменений, независимым мониторингом и регулярным пересмотром ролей.
Команда обнаружила, что разработчик мог изменить правило доступа, сам подтвердить изменение и немедленно применить его к рабочей системе. Вариант с единой административной ролью был простым, но оставлял полный риск компрометации одной учётной записи. Вариант с ручным согласованием через корпоративный чат был удобнее, но не обеспечивал проверяемой связи между одобрением и фактическими параметрами изменения.
Выбрали отдельный процесс: разработчик создаёт неизменяемый запрос на изменение, владелец системы одобряет именно эту версию, а автоматизированный исполнитель применяет только одобренный запрос. Исполнитель не может менять политику одобрения, а все этапы отправляются в отдельное хранилище аудита.
Это увеличило время выпуска изменений и потребовало процедуры для аварийных исправлений, зато компрометация учётной записи разработчика больше не давала единоличного пути к изменению рабочих правил. Попытка изменить запрос после одобрения приводила к необходимости нового согласования.
Нет. Если обе учётные записи управляются одним человеком, используют один секрет или контролируются тем же администратором, независимость может быть иллюзорной. Нужно разделять не только идентификаторы, но и полномочия на выдачу, отзыв и восстановление доступа, а также контролировать общие точки обхода.
Одобритель должен видеть существенные параметры операции и иметь возможность понять её последствия. Система должна запрещать изменение одобренных данных без нового согласования, учитывать срок действия решения и регистрировать, кто и что именно подтвердил. Автоматическое одобрение по шаблону допустимо только для заранее ограниченных низкорисковых случаев, а не для всех привилегированных операций.
Следует уменьшить объём единоличной привилегии и компенсировать совмещение независимыми контролями: временным доступом, автоматическим исполнением неизменяемого запроса, внешним журналированием и последующей проверкой другим ответственным лицом. Это слабее полноценного разделения, потому что не предотвращает действие в момент его выполнения, но повышает обнаруживаемость и ограничивает продолжительность злоупотребления. Компенсирующие меры нужно явно задокументировать и периодически проверять.