В современном цифровом мире кибербезопасность становится одним из приоритетов любой технологической компании. Особое внимание уделяется защите конечных устройств — ноутбуков, рабочих станций и мобильных компьютеров сотрудников, поскольку именно через них зачастую злоумышленники проникают в корпоративные сети и получают доступ к критически важным данным. Компания Figma, стремясь обеспечить надежную защиту своих ноутбуков, сделала ставку на использование Santa — открытого инструмента для бинарной авторизации, разработанного Google, который позволяет ограничивать запуск на устройствах только заранее одобренных приложений. История внедрения Santa в Figma — это пример успешного баланса между требованием к безопасности и комфортом сотрудников, а также продуманной стратегии развертывания, ориентированной на пользователя. Именно о том, как Figma преодолела вызовы и внедрила Santa со стопроцентным охватом своих ноутбуков, пойдет речь далее.
В основе безопасности конечных устройств лежит принцип ограничения запускаемых приложений, что снижает риск проникновения вредоносного ПО и ограничивает потенциальную поверхность атаки. Бинарная авторизация — процесс, позволяющий запускать на устройстве лишь строго проверенные и одобренные исполняемые файлы, — становится важной частью современной защиты. Но реализация такой политики часто связана с рисками и сложностями: инструменты бинарной авторизации могут мешать работе сотрудников, блокировать нужные им инструменты и тем самым снижать производительность. Чтобы избежать этих проблем, Figma сначала внедрила Santa в режим мониторинга, который позволяет собирать детальную статистику запусков программ без их блокировки. Такой подход дал специалистам по безопасности возможность понять, какие приложения и в каких объемах используются, определить образцы и исключения, и на основе полученных данных создать максимально точный и эффективный список разрешенных программ — allowlist.
Одной из особенностей Santa является поддержка нескольких типов правил. К примеру, правила по хешу бинарника (SHA-256) позволяют точно идентифицировать отдельные исполняемые файлы, но требуют постоянного обновления при выходе новых версий приложений. Другой способ — правила по TeamID и SigningID Apple — позволяют разрешать все бинарники, подписанные определенным разработчиком или командой, что облегчает управление списками в случае сложных программных комплексов с множественными компонентами. Однако такой подход менее точен и требует тщательного анализа, чтобы не допустить случайного разрешения нежелательных приложений. Figma смогла выстроить грамотную стратегию, балансируя между этими двумя вариантами: преимущественно использовать SigningID для максимальной точности и прибегать к TeamID только в тех случаях, когда это оправдано доверительными отношениями с разработчиками и масштабом их приложений.
В ходе мониторинга Figma столкнулась с тремя основными типами неизвестных (UNKNOWN) бинарников, которые требуют особого внимания при переходе на жёсткий режим блокировки. Во-первых, это приложения, подписанные разработчиками, для которых еще не было создано правил. Во-вторых, локально собранные бинарники, не подписанные официальным идентификатором, и, наконец, пакеты из менеджеров программного обеспечения, таких как Homebrew или npm, которые часто обновляются и потому имеют изменяющийся хеш. Для локально разрабатываемых бинарников Figma ввела специально разработанные правила компилятора, чтобы не нарушать рабочие процессы разработчиков. Для пакетов с частыми обновлениями была создана автоматизированная система правил, генерирующая новые точные хеши бинарников каждые 30 минут, обеспечивая постоянное обновление allowlist и исключая ненужные блокировки после апдейтов.
Ключевой момент в успешном внедрении бинарной авторизации — минимизация сбоев рабочего процесса сотрудников. В Figma разработали удобный и интуитивно понятный механизм взаимодействия с пользователями при возникновении блокировок. Вместо внедрения сложных графических интерфейсов на клиентских машинах, компания использовала корпоративный Slack как основной канал обратной связи и самодеятельности. Если Santa блокировал приложение, информация об этом сразу поступала в Slack, где пользователь мог получить подробности, убедиться в отсутствии вредоносного ПО и самостоятельно одобрить запуск заблокированного исполняемого файла для своего устройства. При этом весь процесс сопровождался проверками безопасности, например, интеграцией с базой вредоносных программ и внутренними политиками компании.
У пользователей также была возможность быстро получить поддержку от команды безопасности для ручного рассмотрения спорных случаев. Одной из технических сложностей стала необходимость ускорения синхронизации правил между сервером и конечным устройством. В стандартной конфигурации Santa обновления правил приходят с задержкой до минуты, что для сотрудника, неожиданно столкнувшегося с блокировкой, трансформируется в неприятный цикл повторяющихся ограничений. Чтобы решить эту проблему, в Figma создали внутренний сервис, который через API может мгновенно запускать синхронизацию правил на устройстве, сокращая время от одобрения до применения изменений с минуты до нескольких секунд. Это существенно улучшило восприятие системы и повысило удовлетворенность сотрудников.
Важной частью процесса стал поэтапный rollout. Figma начала с небольших групп сотрудников, которые по результатам мониторинга использовали только одобренные приложения и имели минимальное число неизвестных бинарников. Постепенно в охват включались пользователи с более сложными кейсами и большим количеством нестандартизированных приложений, в том числе инженеры и дата-сайентисты, для которых приложение стандартных правил требовало дополнительного настройки и создания комплексных политик. Для таких групп была внедрена система групповых правил, которая позволяла создавать гибкие и безопасные разрешения, ограниченные рамками конкретных команд и проектов. В ходе внедрения также была предусмотрена команда отключения жесткого режима через Slack, чтобы сотрудники могли переключить устройство в мониторинг и продолжить работу без сбоев, пока специалисты безопасности не устранят причину блокировки.
Спустя более года владения Santa в режиме блокировки, Figma достигла полного охвата корпоративной флиты. В компании действует глобальный список разрешенных приложений, включающий порядка 150 правил, охватывающих популярные и востребованные программы, и при этом активен блок-лист на около 50 нежелательных приложений, таких как удалённые администраторские инструменты. Система пакетных правил ежедневно поддерживается в актуальном состоянии благодаря автоматизированному обновлению хешей и позволяет быстро пропускать обновления популярных пакетов без риска блокировки. Количество блокировок в пиковые недели не превышает 3-4 случая, и более 90% из них решатся сотрудниками самостоятельно через Slack. Несмотря на успех, команда Figma столкнулась и с рядом технических сложностей.
Особенно трудным оказался кейс с использованием команды go run, которая напрямую компилирует и запускает бинарник, создавая гонку состояний, в которой Santa не успевает создать правило для нового файла, из-за чего происходит блокировка. Решение было найдено с внесением изменений в скрипты и настройкой исключений. Кроме того, на начальных этапах выросли синхронизационные задержки из-за большого количества автоматизированных правил — порядка 80 тысяч, что приводило к частичному завершению процесса загрузки правил и вызвало внеплановые блокировки. Для уменьшения рисков были введены специальные статические правила для ключевых приложений, обеспечивающие работоспособность независимо от текущего состояния синхронизации. Опыт Figma дает важные уроки для компаний, стремящихся повысить безопасность конечных устройств.
В первую очередь, необходим тщательный и продуманный мониторинг, чтобы не допустить резких ограничений, мешающих сотрудникам выполнять задачи. Второй момент — создание механизма быстрой и понятной обратной связи и расширенных возможностей самоуправления пользователей, что значительно снижает нагрузку на службу поддержки и ускоряет процесс решения проблем. Важно иметь технологические решения, позволяющие автоматизировать обновление правил и минимизировать ручной труд. Кроме того, разбивка на пилотные и основные фазы, с разрешением временных отключений и гибкими политиками для разных групп, значительно снижает риски внедрения новых мер безопасности. В итоге, внедрение Santa в Figma стало примером того, как можно повысить безопасность конечных устройств на высоком уровне без ущерба для продуктивности и комфорта сотрудников.
Автоматизация, внимательное отношение к UX, прозрачность процессов и поэтапное развертывание позволили компании достигнуть цели и заложить фундамент для дальнейшего укрепления корпоративной безопасности. Для других организаций, рассматривающих внедрение бинарной авторизации, опыт Figma станет ценным примером успешной практики, показывающей, что безопасность и удобство вполне могут идти рука об руку.
