Идея этого проекта пришла мне в голову около семи лет назад, но до реализации я добрался только сейчас, т.к. есть некоторое время на это, пока ищу новую работу. Ну, и важно упомянуть, что я уже более 10 лет занимаюсь русской локализацией продуктов и сервисов Mozilla.
Мы привыкли говорить о защите серверов, рабочих станций, сетевого периметра, удостоверяющих систем, средств контроля доступа и ещё десятка важных вещей. Но браузер в организациях при этом слишком часто остаётся где-то в серой зоне. Он как будто есть сам по себе: установлен, как-то настроен, где-то применяются политики — и на этом разговор обычно заканчивается.
Хотя на практике браузер давно уже не просто программа для просмотра сайтов. Это рабочий шлюз ко всему: внутренним системам, облачным службам, корпоративной почте, документообороту, административным панелям, порталам, личным кабинетам и множеству других сервисов, через которые в компании реально проходят данные и процессы. Именно об этом я недавно писал в BIS Journal, где попытался показать браузер как важное, но часто недооценённое звено корпоративной кибербезопасности.
Для меня эта тема не случайна. Раньше я занимался развитием продукта X-Config в Spacebit — решения, связанного с безопасностью конфигураций программного обеспечения. Тогда мне пришлось довольно глубоко погрузиться в саму логику безопасной настройки: как появляются профили, как они согласуются, где заканчивается методология и начинается ручная рутина, почему даже хорошие требования без нормального инструментария быстро превращаются в набор разрозненных действий. В интервью для «Банковского обозрения» мы как раз обсуждали профили безопасного конфигурирования, роли специалистов по ИБ и администраторов, а также то, что такие профили должны жить не как памятка в PDF, а как часть управляемого процесса.
В какой-то момент мне стало очевидно, что браузер ничем не хуже и ничем не проще любого другого критичного клиентского ПО. Более того, во многих организациях он даже чувствительнее. Через него сотрудники работают с самыми важными системами, а значит, вопрос его настроек — это уже не вопрос удобства, а вопрос управляемости и, в конечном счёте, безопасности.
Так и появился Browser Policy Manager — мой открытый проект под лицензией MPL 2.0.
Мне не хотелось делать просто ещё один генератор JSON или YAML. Таких вещей при желании можно написать сколько угодно: отрисовать форму, собрать итоговый файл и считать задачу решённой. Но в реальной жизни файл — это только последний шаг. До него обычно есть выбор сценария, набор решений, правки, сравнение с предыдущим вариантом, обсуждение с коллегами, откат, повторное сохранение и попытка понять, что именно изменилось.
Поэтому я стал строить проект не вокруг «файла политик», а вокруг профиля политик как отдельной сущности. Такой профиль можно создать, проверить, сравнить, доработать, сохранить, архивировать, восстановить и выгрузить в нужном виде. Иными словами, мне было важно описать не только результат, но и жизненный цикл этой конфигурации. Эта логика сейчас уже довольно явно отражена в основной документации проекта.
Сейчас Browser Policy Manager сосредоточен на корпоративных политиках Firefox. В основной ветке проект уже ушёл от совсем раннего состояния: есть интерфейс работы с профилями /profiles, отдельный набор маршрутов /api/profiles, проверка политик по схеме, сравнение профилей, сценарий «клонировать и доработать», архивирование и восстановление, а также выгрузка в JSON и YAML. Поддерживаются встроенные схемы Firefox ESR 140.9 и Release 149.
Что для меня в этом проекте принципиально: пошаговая настройка, прямое редактирование техдокумента, проверка, сравнение и выгрузка должны быть не разными мирами, а разными представлениями одного и того же состояния. Иначе инструмент очень быстро начинает плодить собственную путаницу. Именно поэтому в проекте мастер профилей и режим «Техдокумент» не противоречат друг другу, а должны работать как две стороны одной модели. В README эта идея сформулирована довольно прямо: одна каноническая модель должна питать интерфейс, API, расширенное редактирование, проверку, просмотр и экспорт.
Под капотом здесь FastAPI, SQLAlchemy, Alembic и SQLite по умолчанию; для веб-части используется Jinja2, а для расширенного редактирования — встроенный комплект статических файлов и редактор Monaco. В последних изменениях проект заметно сместился от просто «редактора политик» в сторону более цельного рабочего контура: с мастером профилей, сравнением по областям настройки, обзором жизненного цикла, выжимкой для передачи коллегам и более строгой увязкой всего этого вокруг единой модели профиля.
Для меня особенно важно, что проект с самого начала был готов к локализации. Сейчас в нём уже есть английская и русская локализации интерфейса, и это не декоративная добавка «на потом», а часть текущей структуры проекта. Русская терминология при этом уже отдельно вычищалась и приводилась к более последовательному виду.
Почему я решил написать об этом именно сейчас? Потому что это та стадия, когда проект ещё можно критиковать по существу и без больших потерь что-то менять в архитектуре.
Я сознательно остановиля на Firefox, чтобы сначала довести до ума один предметный участок, а не пытаться сразу охватить все браузеры и всё разом.
Если у вас есть опыт работы с корпоративными браузерами, централизованной настройкой рабочих мест, безопасностью клиентского ПО или просто с Firefox в организациях, мне особенно интересна обратная связь по нескольким вопросам.
Во-первых, нужен ли вообще отдельный инструмент такого класса, или это задача, которую правильнее решать средствами управления конфигурациями, групповыми политиками и собственными сценариями автоматизации.
Во-вторых, где здесь должна проходить граница между мастером и прямым редактированием.
В-третьих, чего проекту не хватает в первую очередь: импорта существующих policies.json, более сильного режима сравнения, более удобного обзора изменений, поддержки других браузеров или чего-то ещё.
Проект открыт, код открыт, лицензия открытая. Поэтому буду рад не только комментариям под публикацией, но и предметным замечаниям по коду, архитектуре и логике развития.
