Browser Policy Manager: история создания и технические решения

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

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

У Firefox для этого есть корпоративные политики. Их можно описывать в policies.json, раскладывать по рабочим станциям и получать управляемый браузер. Но между «политики существуют» и «администратор или специалист по информационной безопасности может уверенно сопровождать их в реальной организации» есть большая дистанция.

Так появился Browser Policy Manager — свободный продукт под лицензией MPL-2.0 для управления корпоративными политиками Firefox.

Откуда взялась идея

Идея появилась не вчера. Впервые я начал думать об отдельном инструменте для управления политиками Firefox примерно восемь лет назад.

Причин было несколько.

Во-первых, вручную писать и сопровождать policies.json неудобно. На уровне небольшого примера это выглядит просто: открыть документацию, взять несколько политик, собрать JSON, положить файл в нужное место. Но в реальной работе быстро появляются вопросы: почему выбраны именно эти настройки, что изменилось между версиями, можно ли сравнить два варианта, какие параметры относятся к безопасности, какие требуют согласования, какие появились только в новых версиях Firefox.

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

В-третьих, мой опыт в информационной безопасности постоянно возвращал меня к теме безопасных конфигураций. В Spacebit я развивал продукт X-Config, связанный с безопасностью конфигураций программного обеспечения. Когда мы смотрели на возможность качественно добавить поддержку Firefox, стало заметно, что информации и инструментов вокруг этой темы недостаточно. Браузер вроде бы распространённый, важный, технически зрелый, но предметная область управления его корпоративными настройками остаётся довольно узкой и фрагментированной.

Изначально я думал о Browser Policy Manager как о коммерческом продукте. Но для такого проекта нужны ресурсы: разработка, методология, документация, проверка на реальных сценариях, продвижение. Инвесторов найти не удалось, идея осталась лежать в долгом ящике.

Вернулся я к ней уже в другой ситуации. За последние месяцы, находясь в активном поиске работы, я решил, что можно не ждать идеального момента и не пытаться сначала собрать команду. У меня есть предметный опыт, продуктовый опыт, понимание Mozilla и современные инструменты разработки с использованием искусственного интеллекта. Этого оказалось достаточно, чтобы начать делать продукт самостоятельно.

Почему это не просто генератор JSON

Самый простой путь был бы очевиден: сделать форму, несколько полей, кнопку «Скачать policies.json». Такой инструмент можно написать достаточно быстро. Но в реальной эксплуатации этого мало.

Файл — это последний шаг. До него есть жизненный цикл конфигурации:

• создать профиль;

• выбрать целевой канал Firefox: Release или ESR;

• настроить политики;

• проверить результат;

• сравнить с другим профилем;

• понять, что изменилось;

• сохранить версию;

• передать коллегам;

• выгрузить в policies.json;

• при необходимости вернуться и внести изменения.

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

Один и тот же профиль можно открыть через мастер, через библиотеку профилей, через сравнение, через полный каталог настроек или через JSON-редактор. Это разные рабочие поверхности, но они должны работать с одним источником данных. Иначе продукт быстро превратился бы в набор разрозненных экранов, где пользователь сам должен помнить, что где было изменено.

Для меня это было ключевым продуктовым решением: Browser Policy Manager должен быть не «обёрткой над JSON», а рабочей средой для жизненного цикла браузерных конфигураций.

Лицензия и открытость

Проект распространяется под MPL-2.0. Для меня это естественный выбор по нескольким причинам.

Первая причина — связь с экосистемой Mozilla. Browser Policy Manager работает с Firefox, я давно участвую в локализации Mozilla, и сама предметная область проекта близка к этой культуре открытости.

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

Третья причина — прагматичность. Для администраторов и специалистов по информационной безопасности важно, чтобы инструмент можно было проверить, развернуть у себя, адаптировать, встроить в собственные процессы. Закрытый «чёрный ящик» здесь выглядел бы хуже, особенно если речь идёт о настройках безопасности.

Основные вехи развития

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

После MVP появились следующие важные этапы.

Мастер создания профиля

Мастер нужен для типовых сценариев. Не каждый пользователь хочет начинать с полного каталога политик или с JSON. Администратору часто нужно быстро собрать понятный базовый профиль: настройки доступа, обновлений, расширений, приватности, безопасности, поведения браузера.

Мастер решает именно эту задачу: он ведёт пользователя по шагам и скрывает избыточную сложность там, где она не нужна.

Библиотека профилей

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

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

Сравнение профилей

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

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

Поддержка CIS

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

Здесь важно не свести всё к кнопке «сделать безопасно». В реальных организациях требования нужно просматривать, адаптировать, иногда принимать исключения. Поэтому поддержка CIS в Browser Policy Manager развивается не как магический набор предустановок, а как часть рабочего процесса: профиль, рекомендации, ручная проверка, источники настроек и дальнейшее сопровождение.

Полный каталог настроек Firefox

Мастер хорош для типовых сценариев, но он не должен быть потолком продукта. Администратору или специалисту по безопасности иногда нужен полный контроль: найти конкретную политику, посмотреть доступные параметры, включить редкую настройку, проверить, как она будет выглядеть в итоговом policies.json.

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

Эта проблема стала центральной для версии 0.8.8.

Что меняется в 0.8.8

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

Главная задача 0.8.8 — превратить All settings из длинного каталога в рабочую поверхность для настройки и проверки профиля.

Раньше полный каталог решал задачу доступа ко всем настройкам. Но когда в профиле появляются базовые политики, CIS, ручные правки, импортированные параметры и возможные ошибки проверки, пользователю уже недостаточно просто видеть всё подряд. Ему нужно понимать:

• что требует внимания;

• что уже настроено;

• что пришло из базового профиля;

• что связано с CIS;

• что было изменено вручную;

• какие настройки доступны, но ещё не используются;

• где есть неподдерживаемые или неизвестные параметры;

• как быстро перейти к нужной политике.

Поэтому в 0.8.8 All settings разделяется на несколько режимов.

Review — режим проверки. Он должен показывать в первую очередь то, что требует внимания: ошибки, ручные решения по CIS, неизвестные или импортированные параметры, спорные состояния.

Configured — режим настроенных параметров. Здесь пользователь видит не весь каталог, а то, что уже реально влияет на профиль. Это важно для анализа, согласования и сопровождения.

Catalog — полный каталог. Он остаётся доступным, но больше не является первым экраном для тяжёлого корпоративного профиля.

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

Архитектура: почему именно такой стек

Browser Policy Manager сделан как веб-приложение на FastAPI. Это прагматичный выбор: FastAPI даёт удобный способ строить API, подключать проверку данных, развивать маршруты и при этом не перегружать проект лишней инфраструктурой.

Веб-интерфейс построен на Jinja2 и серверном HTML, а не на отдельном большом приложении на стороне браузера. Это осознанное решение. Для такого продукта важны понятные маршруты, предсказуемая структура, простое развёртывание и возможность одному человеку поддерживать кодовую базу. Отдельный сложный интерфейсный стек добавил бы скорости на отдельных участках, но одновременно увеличил бы число движущихся частей.

Сейчас в продукте есть несколько основных рабочих поверхностей:

• библиотека профилей;

• мастер создания и редактирования профиля;

• сравнение профилей;

• полный каталог настроек;

• JSON-редактор;

• импорт, экспорт и проверка.

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

Для хранения используется SQLAlchemy, миграции управляются через Alembic, по умолчанию применяется SQLite. Для текущего этапа это разумная комбинация: можно развивать нормальную модель данных, иметь миграции, хранить профили и версии, но не требовать от пользователя отдельной тяжёлой инфраструктуры для первого запуска. При этом архитектура не должна закрывать путь к более серьёзному развёртыванию.

Отдельный слой связан со схемами политик Firefox. Browser Policy Manager должен понимать разные версии Firefox: Release и ESR. Выбранная схема влияет на проверку, доступные элементы интерфейса и итоговый экспорт. Это важно, потому что корпоративная среда часто живёт на ESR, а новые политики появляются в актуальных выпусках Firefox.

Единая модель профиля

Одна из главных архитектурных идей — единая модель профиля.

Пользователь может идти разными путями:

• начать с мастера;

• импортировать существующий policies.json;

• открыть полный каталог;

• изменить настройки через JSON-редактор;

• сравнить профиль с другим;

• выгрузить итоговый файл.

Но все эти действия должны сходиться в одном состоянии. Это позволяет не плодить отдельные «версии правды» для разных экранов.

Такой подход особенно важен для управляемых настроек Firefox. Есть политики, есть Preferences, есть настройки, которые пришли из импорта, есть будущие источники вроде CIS или базовых корпоративных профилей. Если всё это не свести в одну модель, интерфейс быстро станет противоречивым.

В версии 0.8.8 эта идея развивается дальше: для All settings появляется единая модель инвентаря настроек. Она должна описывать настройку не только как строку в таблице, а как объект с типом, категорией, состоянием, источниками, признаками внимания, связью с редактором и результатами проверки.

Иными словами, настройка в интерфейсе должна отвечать не только на вопрос «что это за параметр?», но и на вопросы «почему он здесь?», «откуда он пришёл?», «требует ли внимания?», «где его редактировать?» и «как он попадёт в итоговый файл?».

Почему интерфейс — одна из самых сложных частей

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

У Firefox много корпоративных политик и управляемых настроек. Если просто показать всё, получится справочник. Справочник полезен, но он плохо отвечает на вопросы реальной работы: что уже настроено, что опасно, что требует решения, что изменилось, что надо проверить перед внедрением.

Поэтому в Browser Policy Manager интерфейс развивается вокруг нескольких принципов.

Первый принцип — сначала сводка, потом детали. Пользователь должен сначала увидеть состояние профиля, а не утонуть в длинном списке.

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

Третий принцип — детали по требованию. Длинные объекты, массивы, технические значения и полная JSON-структура должны быть доступны, но не обязаны занимать основной экран.

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

Проверка качества

Для продукта, который управляет настройками безопасности, недостаточно принципа «на моей машине работает».

В Browser Policy Manager я держу покрытие кода на уровне 100%. Это не самоцель ради красивой цифры, но полезная дисциплина. Когда проект развивается быстро и значительная часть разработки идёт с помощью Codex, тесты становятся страховочной сеткой. Они позволяют чаще делать рефакторинг и не бояться, что очередное изменение сломает соседний сценарий.

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

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

Локализация как часть архитектуры

Поскольку мой путь в Mozilla во многом связан с локализацией, я с самого начала не хотел относиться к переводу интерфейса как к украшению на потом.

В Browser Policy Manager поддерживается шесть локалей. Исходный язык интерфейса — английский, но структура проекта должна позволять развивать другие языки без хаоса в строках, ключах и терминах.

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

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

Codex как второй разработчик

Отдельно стоит сказать про инструменты разработки. Browser Policy Manager я сейчас веду один, но активно использую Codex.

Я не воспринимаю это как «нажал кнопку — получил продукт». Скорее это похоже на работу со вторым разработчиком, которому нужно ставить задачи, объяснять контекст, проверять результат и принимать архитектурные решения самостоятельно.

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

Это важное различие. Искусственный интеллект может ускорить разработку, но он не заменяет понимание предметной области. В Browser Policy Manager нужно учитывать Firefox, корпоративные политики, безопасные конфигурации, сценарии администрирования, локализацию, удобство интерфейса и сопровождение продукта. Без человека, который держит всё это в голове и принимает решения, код сам по себе не превращается в продукт.

На практике работа с Codex заставила меня строже формулировать задачи. Хорошая задача должна включать контекст, границы, ожидаемое поведение, проверки, запреты и критерии приёмки. Это очень похоже на работу технического продакт-менеджера или архитектора с командой: чем точнее постановка, тем меньше случайных решений появляется в реализации.

Автоматизация обновления схем Firefox

Одна из важных технических задач — поддержка новых версий Firefox. Политики меняются: появляются новые параметры, часть возможностей зависит от Release или ESR, какие-то настройки доступны только в новых версиях.

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

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

Для корпоративного инструмента это особенно важно. Пользователь должен понимать, какая версия Firefox поддерживается, какие политики доступны в Release, какие в ESR, и почему конкретная настройка есть или отсутствует в интерфейсе.

JSON-редактор и экспорт

При всём внимании к мастер-сценариям и визуальному каталогу, прямой доступ к policies.json остаётся важным. В корпоративной эксплуатации всегда будут пользователи, которым нужен полный контроль над итоговым документом.

Поэтому в продукте есть JSON-редактор и экспорт. Это не запасной выход для случаев, когда «нормальный интерфейс не справился», а полноценная рабочая поверхность для тех, кто хочет видеть технический документ напрямую.

Здесь снова работает идея единой модели: визуальный интерфейс и JSON не должны противоречить друг другу. Пользователь может работать через мастер, каталог или JSON, но итоговая конфигурация должна оставаться согласованной.

Почему документация станет частью продукта

Следующий крупный шаг после 0.8.8 — версия 0.9.0. В ней я планирую реализовать раздел документации на базе DITA-OT и единого источника.

Это не просто «добавить справку». Для такого инструмента документация должна быть частью продукта. Администратор или специалист по безопасности часто задаёт не абстрактный вопрос «что делает эта политика?», а очень конкретный: зачем она нужна, как она связана с безопасностью, применима ли она к моей версии Firefox, как она соотносится с CIS, как её проверить, как экспортировать результат и как встроить это в существующий процесс управления конфигурациями.

В 0.9.0 документация должна покрывать несколько направлений из одного источника:

• руководство пользователя;

• руководство администратора;

• справку по настройкам политик Firefox;

• справку по CIS;

• руководство по интеграции с другими системами через встроенный API.

DITA-OT здесь интересен именно как способ строить единую модульную документационную базу, а не набор отдельных файлов, которые быстро расходятся между собой.

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

В идеале Browser Policy Manager должен стать местом, где пользователь не только меняет политики, но и понимает, что именно он меняет и почему.

Что получилось на текущем этапе

Сейчас Browser Policy Manager уже вышел за пределы раннего MVP. В продукте есть мастер создания профиля, библиотека профилей, сравнение, поддержка CIS, полный каталог настроек, JSON-редактор, импорт и экспорт policies.json, локализация, проверки и работа с разными версиями Firefox.

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

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

Browser Policy Manager остаётся открытым проектом. Мне интересна обратная связь от тех, кто занимается администрированием рабочих мест, безопасными конфигурациями, Firefox в организациях, внедрением корпоративных браузеров и управлением настройками клиентского программного обеспечения.

Особенно интересны замечания по трём направлениям:

• каких сценариев не хватает администраторам;

• какие проверки и представления были бы полезны специалистам по информационной безопасности;

• как лучше встроить такой инструмент в существующие процессы управления конфигурациями.

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