Политика безопасности браузеров на рабочих местах: централизованные настройки, профили и запрет небезопасных функций

Браузер уже давно перестал быть просто «обозревателем», как его перевели в первых версиях операционной системы Windows, т.е. инструментом, предназначенным для пассивного просмотра статических веб страниц, каким он был в эпоху web 1.0. Динамическое содержимое, приложения с клиент-серверной архитектурой, код, исполняемый прямо в браузере, – все это уже стало стандартом де-факто для любого популярного интернет ресурса. А где есть исполняемый код, там есть и вредоносные программы, выполняемые в виде скриптов самим браузером. Чаще всего такие скрипты перенаправляют на дополнительные веб-страницы или открывают их в фоне, используют ресурсы компьютера для DDOS-атак или майнинга криптовалют, а также скачивают на компьютер жертвы вредоносное содержимое.

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

Cookie-файлы – это удобный инструмент, чтобы сохранять информацию при клиент-серверном взаимодействии. Однако, получив к ним доступ, злоумышленник фактически завладевает сессией пользователя и может авторизовываться на сайте под его учетными данными. Защита от атак подобного рода должна охватывать как защиту пользователя от доступа к его cookie-файлам, так и защиту веб-приложений, причем отличить легитимную сессию от нелегитимной бывает не так просто. В первом случае помимо цифровой гигиены необходимо обеспечивать физическую безопасность устройства, при необходимости использовать шифрование накопителя, чтобы при краже устройства злоумышленник не смог получить доступ к cookie-файлам. Во втором – проектировать веб-приложение с применением подходов безопасной разработки и использовать Web Application Firewall, который при корректной настройке под каждое веб-приложение способен значительно усложнить проведение атак на прикладном уровне. Это важный аспект кибербезопасности и защиты данных.

Современный браузер давно перестал функционировать исключительно локально на одном компьютере, существует (и активно продвигается производителями путем ненавязчивых постоянных напоминаний) возможность создать аккаунт и синхронизировать данные на разных устройствах, например, закладки, сохраненные пароли или набор плагинов. И если первоначальная идея такой возможности была продиктована соображениями удобства пользователя, то на текущий момент она представляет собой недостаточно контролируемый поток информации в защищенную инфраструктуру, либо наоборот – из инфраструктуры во вне. Таким образом в защищаемом контуре могут оказаться ссылки на вредоносные ресурсы, плагины с недекларированной функциональностью, т.е. откровенно шпионские модули, а на домашнем компьютере пользователя – URL-адреса внутренних ресурсов и сохраненные пароли от инфраструктурных сервисов. В конечном итоге получается парадоксальная ситуация: даже если в организации откровенно не приветствуется использование BYOD-подхода, его недостатки всё равно проявляются – чувствительные данные оказываются на домашних компьютерах, а поскольку корпоративные средства защиты на такие компьютеры не устанавливаются, при компрометации все эти данные окажутся в руках злоумышленников. Запретить вход в аккаунты в браузере и соответственно синхронизацию данных можно организационными и техническими мерами. В политиках информационной безопасности крупных организаций нередко упоминается прямой запрет использования личных учетных записей на корпоративных компьютерах (а также наоборот – корпоративных УЗ, в частности адреса электронной почты, на внешних ресурсах) или даже запрет использования синхронизации в браузерах в явном виде. О технических мерах речь пойдет в следующей разделе.

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

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

Плагины или расширения – это компоненты браузера, представляющие собой отдельные программы от сторонних разработчиков, встраиваемые непосредственно в браузер и несущие дополнительный функционал. Плагины в чем-то сходны с Android-приложениями, например, могут распространяться через официальные каналы производителя и проходить ряд проверок на безопасность или устанавливаться пользователями вручную с сайта производителя конкретного плагина в обход этих проверок. Каждый плагин получает определенные права на чтение/изменение информации, отображаемой в браузере, чем могут воспользоваться злоумышленники, разрабатывающие вредоносное программное обеспечение и упаковывающие его в формат плагинов, чтобы какое-то время оставаться незамеченными в системе и заниматься прослушиванием интернет-трафика. Поэтому подход к управлению безопасностью расширений для браузера во многом можно считать похожим на подход к защите корпоративных мобильных устройств от недоверенных вредоносных приложений. Самый радикальный метод – белые списки расширений – потребует определенного периода времени на инвентаризацию и проверку на безопасность используемых плагинов, а также выстраивание процесса по внесению изменений в такой список. Средства антивирусной защиты и EDR смогут обнаружить вредоносный плагин по сигнатурам или поведению. Это важный элемент обеспечения кибербезопасности в организации.

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

Источник: CISOCLUB