После взлома корпоративного аккаунта в соцсети (злоумышленник опубликовал мошеннический пост со ссылкой) выяснилось, что доступ к аккаунту за два года работы получили больше 20 человек из нескольких агентств, а часть паролей не менялась годами. Как спроектировать модель управления доступами и реагирования на инциденты, чтобы снизить риск подобного в будущем?

Короткий ответ

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

Как это работает подробнее

ролевой доступ в стиле бизнес-менеджера позволяет каждому человеку/агентству получить только нужный уровень прав при централизованной видимости, у кого есть доступ к чему; протестированный план реагирования (заранее определённые роли: кто связывается с поддержкой площадки, кто готовит публичное заявление, кто оценивает ущерб) сокращает время реакции в момент реального инцидента. строгая модель (частая смена паролей, обязательные аппаратные ключи 2FA, еженедельные аудиты) заметно снижает риск, но увеличивает административную нагрузку на команду и подрядчиков и может замедлять операционную работу; более мягкая модель быстрее в повседневной работе, но оставляет больше окон для компрометации. Выбор зависит от размера бренда, числа внешних подрядчиков, чувствительности аудитории к репутационным инцидентам и готовности команды поддерживать процесс — единственно верной степени строгости нет, и её стоит пересматривать после любого инцидента или роста числа вовлечённых сторон.

Что использовать на практике

• Действия. Нужно выстроить централизованное управление доступами (единый источник правды о том, у кого какой доступ, со сроком действия, привязанным к контракту), включить 2FA/аппаратные ключи там, где это поддерживается, назначить регулярные аудиты доступов и периодически проводить учебную симуляцию компрометации аккаунта.
• Проверка. После инцидента внедрена централизованная таблица доступов с обязательным 2FA, доступ агентств ограничен ролью без прав смены пароля/почты аккаунта, и проведена первая тренировка по плану реагирования на условный сценарий взлома. Проверка: время от обнаружения условного «взлома» на тренировке до восстановления контроля над аккаунтом по плану, сравниваемое с целевым показателем, например до одного часа.

Подводные камни

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