«Usable security, это не про удобство, а про выживаемость системы в реальных условиях. Когда пользователь вынужден обходить защиту, чтобы просто сделать свою работу, формальное соответствие 152-ФЗ и ФСТЭК становится фикцией. Реальная безопасность возникает там, где инженерное решение делает легитимные действия простыми, а обходные — невыгодными.»
Почему безопасность и удобство — не полюса, а одна система
Метафора весов, где на одной чаше безопасность, а на другой — удобство, вводит в заблуждение. В реальных системах это не конкурирующие параметры, а взаимозависимые свойства. Неудобная защита провоцирует создание уязвимостей самими пользователями: сложные пароли записываются на стикерах, токены передаются коллегам, а критические обновления откладываются из-за страха сломать рабочий процесс.
В рамках 152-ФЗ и требований ФСТЭК этот разрыв становится системной проблемой. Регуляторные акты предписывают наличие средств защиты, но почти не регламентируют эргономику их использования. В итоге аттестованный по всем пунктам комплекс может быть нефункционален в ежедневной эксплуатации, создавая у руководства ложное ощущение защищённости, в то время как реальные риски растут.
Кривые принятия решений: как пользователь выбирает между «сделать» и «обойти»
Пользователь не оценивает корпоративные риски. Он подсчитывает личные издержки: время, умственное усилие, вероятность неудачи. Если стоимость соблюдения правила превышает стоимость его нарушения, правило будет проигнорировано. Это не саботаж, а рациональное экономическое поведение в рамках заданной системы.
Эту динамику можно представить графически. Для каждой операции существует порог приемлемой сложности. Задача проектировщика — спроектировать легитимные сценарии так, чтобы они оставались ниже этого порога, одновременно поднимая барьер для злонамеренных действий за счёт архитектуры, а не бесконечных запросов к пользователю.
Российская специфика: 152-ФЗ, ФСТЭК и человеческий фактор
Предписывающий характер требований ФСТЭК часто приводит к механическому внедрению. Требуется двухфакторная аутентификация — внедряется решение, где вторым фактором выступает СМС на личный номер или токен без внятной процедуры восстановления. Формально требование выполнено, но на практике это приводит к:
- Сопротивлению сотрудников и давлению на отдел ИБ со стороны бизнес-подразделений.
- Появлению неучтённых «серых» схем доступа.
- Простоям в работе при потере или поломке токена.
Выход — вводить эргономические требования на уровне технического задания. Вместо «реализовать усиленную аутентификацию» — «обеспечить авторизацию в систему не более чем за три действия, с возможностью восстановления доступа в течение одного рабочего дня без визита к системному администратору». Это смещает фокус с наличия инструмента на его практическую применимость.
Принципы проектирования usable security в условиях регуляторики
Создание систем, одновременно безопасных и пригодных к использованию, требует смены парадигмы: от контроля к проектированию.
1. Минимизация точек принятия решений
Каждый диалог с пользователем («Подтвердите действие», «Введите код из СМС»), это точка отказа. Их избыток ведёт к «слепому кликанью», когда предупреждения системы просто игнорируются. Критичные решения должны приниматься редко, но осознанно. Опасные действия должны быть архитектурно затруднены, а не просто сопровождаться всплывающим окном.
2. Контекстная безопасность
Жёсткость проверок должна масштабироваться в зависимости от риска. Доступ к тестовому стенду из офисной сети — один сценарий. Доступ к продакшен-базе с персональными данными с нового устройства из другой страны — кардинально другой. Современные отечественные СЗИ и системы управления доступом позволяют настраивать такие адаптивные политики, снижая нагрузку на пользователя в низкорисковых сценариях.
3. Прозрачность и обучаемость
Блокировка без объяснения причин порождает враждебность. Отказ в доступе должен сопровождаться внятным сообщением, указывающим на причину и следующий шаг. Например: «Вход заблокирован: превышено количество попыток с вашего IP-адреса (192.168.1.1). Доступ будет автоматически восстановлен через 15 минут. Код инцидента: RBAC-2025-0451». Это превращает пользователя из проблемы в элемент системы мониторинга.
Инструменты и методы оценки
Проверить, насколько система соответствует принципам пригодной безопасности, можно несколькими способами.
| Метод | Суть | Что выявляет |
|---|---|---|
| Юзабилити-тестирование сценариев ИБ | Наблюдение за реальными пользователями, выполняющими задачи (восстановление доступа, подписание ЭЦП). | Фактическое время, количество ошибок, точки фрустрации, приводящие к поиску обходных путей. |
| Аудит логов на предмет обходных путей | Анализ журналов на предмет аномалий: использование общих учётных записей, частые сбросы паролей, отключения средств защиты. | Косвенные индикаторы неудобных или нерабочих процедур безопасности. |
| Сравнительный анализ (бенчмаркинг) | Сопоставление ключевых метрик (число шагов для 2FA, время на подписание документа) с внутренними стандартами или отраслевыми практиками. | Отклонения от целевых показателей удобства, области для улучшения. |
Итог: безопасность как свойство системы, а не надстройка
Главный вывод для специалистов, работающих в поле 152-ФЗ: безопасность нельзя «внедрить» как отдельный продукт. Её необходимо проектировать изначально как неотъемлемое свойство системы, учитывающее человеческое поведение. Компромисс между безопасностью и удобством, это не поиск середины, а поиск архитектурных решений, которые делают соблюдение правил самым простым путём для пользователя. Система, с которой пользователю приходится бороться, обречена на фиктивную безопасность. Настоящая защита начинается там, где пользователь, даже не задумываясь, действует безопасно.