Невидимая безопасность. Как сделать так, чтобы пользователи не страдали

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

Ниже мы рассмотрим сценарии, как внедрение безопасности в среднестатистической организации обычно проходит, может проходить и должно проходить.

Архитектура с безопасностью по умолчанию

Во многих компаниях безопасность исторически надстраивается поверх уже существующей архитектуры. Система, ранее спроектированная совсем под другие масштабы и векторы угроз, по мере роста бизнеса, регуляторного давления и числа инцидентов вместо того, чтобы быть перестроенной, обрастает «костылями». Такие костыли включают, но не ограничиваются новым VPN (желательно еще и поверх старого), дополнительными паролями на доступы к новым ресурсам, использование MFA для всех без исключения сценариев, и созданием отдельных контуров «на всякий случай», доступных также через VPN.

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

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

Политики и регламенты как организационный технический долг

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

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

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

Именно здесь появляется пространство для диалога между CISO, владельцами процессов и продуктовыми командами.

От модели заграждений к невидимой безопасности

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

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

• внедрение подхода, принимающего безопасность как часть процесса создания архитектуры. Здесь безопасник становится частью команды разработки с самого первого дня, участвуя во всех архитектурных обсуждениях и проработке векторов атак и средств защиты от них. В противовес распространенной модели «согласований перед запуском», когда владельцу продукта, помимо основных задач, нужно любым образом пройти дополнительный уровень с безопасником. Разница в результатах очевидна; 
• разработка CJM для системы безопасности, в частности, опыт и мнение ключевых пользователей системы, мониторинг системы, рабочее место оператора безопасности, централизованный сбор логов и пр.;
• составление карты существующего технического долга безопасности, включая жалобы пользователей, и приоритизация его исполнения. Это приведет к устранению имеющихся исключений и временных решений, которые со временем могут стать постоянными;
• разделение объектов по категориям риска и контексту, когда дополнительные проверки подключаются только там, где риск действительно существует.

Читайте также

В России объявлена война серому импорту

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

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

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