Безопасность надстроек Office: метод оценки рисков

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

Я не советую относиться к каждой надстройке как к потенциальной атаке. Это быстро превращает ИТ-службу в отдел запретов, а сотрудников — в людей, которые ищут обходные пути. Но надстройку Office нельзя оценивать по логотипу в магазине, количеству звезд или аккуратному лендингу разработчика. У нее другая модель доверия: приложение может быть опубликовано легитимно, а затем его удаленный контент изменится уже без новой установки на компьютеры пользователей.

Именно поэтому метод оценки рисков здесь строится не вокруг вопроса «полезна ли эта кнопка в Excel», а вокруг трех более практичных: откуда надстройка загружается, какие данные она может читать или менять и кто контролирует ее жизненный цикл после развертывания.

Надстройка — не обычная программа, установленная на ПК

Самая частая ошибка в разговорах о безопасности плагинов для Excel и тестировании расширений для Word — представлять их как локальные программы. В классическом сценарии с десктопным ПО компания получает установщик, подписанный пакет, версию и набор файлов, которые можно проверить и контролировать. У веб-надстроек Office логика иная.

Архитектура строится на HTML, CSS и JavaScript. Office загружает интерфейс и код надстройки с удаленного сервера разработчика во фрейме. XML-манифест сообщает платформе, где находится этот контент, какие команды показать пользователю, на каких клиентах запускаться и какие разрешения запросить.

Это удобно для поставщика: он может исправить интерфейс или добавить функцию без тяжелого цикла обновлений на тысячах устройств. Но именно здесь возникает архитектурная уязвимость, которую специалисты описывают как Mutable Remote Execution — изменяемое удаленное исполнение. Манифест может оставаться прежним, а содержимое по указанному адресу — измениться.

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

Для первичной оценки я раскладываю надстройку на четыре слоя:

1. Издатель и его операционная устойчивость. Кто владеет продуктом, доменом и аккаунтом публикации; есть ли у компании понятный сайт, поддержка, история обновлений и процедура реакции на инциденты. Молодой поставщик не равен небезопасному, но заброшенный проект с неясным владельцем — плохой кандидат на доступ к корпоративной почте.

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

3. Разрешения и контекст работы. Надстройка, которая форматирует таблицу, и надстройка, которая читает и изменяет письма, относятся к разным классам риска, даже если обе работают «в Office».

4. Контур развертывания. Как приложение попало к пользователю: из магазина, через централизованное развертывание или через sideloading. Последний вариант особенно неудобен для контроля, потому что создает исключения из общего процесса.

Надстройка становится риском не в момент появления кнопки в ленте Office, а в момент, когда организация перестает видеть, какой удаленный код стоит за этой кнопкой сегодня.

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

AgreeToSteal: почему заброшенный адрес опаснее новой версии приложения

В феврале 2026 года исследователи описали кампанию AgreeToSteal. Ее ценность для практики не в экзотичности техники, а в том, что она наглядно показывает слабое место модели удаленного контента.

Легитимная надстройка AgreeTo была опубликована в Office Store в декабре 2022 года. Позже злоумышленники получили контроль над заброшенным субдоменом на Vercel — outlook-one.vercel.app, который использовался надстройкой. Пользователи продолжали видеть знакомое приложение в привычной среде Outlook, однако по прежнему адресу уже загружался вредоносный контент. Кампания привела к компрометации более 4 000 учетных записей Microsoft.

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

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

Внутренней команде при оценке рисков сторонних интеграций в Office полезно запросить у поставщика простые, но предметные ответы:

• какие домены и поддомены использует надстройка в рабочем контуре;
• кто отвечает за продление доменов, DNS и учетные записи у хостинг-провайдеров;
• существует ли инвентаризация URL из манифестов и процедура их вывода из эксплуатации;
• как поставщик сообщает клиентам о смене доменной инфраструктуры;
• какой срок реакции предусмотрен, если один из адресов оказался скомпрометирован или недоступен.

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

Что искать в манифесте до пилота

XML-манифест не нужно читать вручную построчно, но его необходимо валидировать и хранить в составе карточки приложения. Официальный инструмент office-addin-manifest позволяет проверить структуру манифеста командой npx office-addin-manifest validate. Для разработчика это базовая техническая гигиена. Для заказчика — разумное требование к поставщику, если надстройка проходит пилот в чувствительном процессе.

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

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

Разрешения: решение пользователя, которое живет дольше его памяти

Когда Outlook просит разрешить доступ к почтовому ящику, пользователь обычно думает о текущей задаче: отправить документ на согласование, перевести письмо, прикрепить данные из CRM. Через несколько недель он уже не помнит, какое приложение получило доступ и в каком объеме. Это нормальное человеческое поведение, а не небрежность.

Проблема в том, что разрешения надстроек запрашиваются при установке. Если пользователь одобрил, например, ReadWriteItem — возможность читать и изменять текущие элементы почты, — это согласие сохраняется. Изменить объем разрешений через обычные настройки нельзя: для пересмотра требуется полностью удалить надстройку и установить ее заново.

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

Для рабочего разбора удобно использовать такую матрицу.

Таблица не заменяет анализ. Она нужна, чтобы бизнес и ИТ говорили на одном языке. Иначе владелец процесса скажет: «Нам нужна интеграция с почтой», а администратор услышит только очередную техническую заявку. Между этими фразами теряются реальные боли пользователя: сколько писем приложение видит, какие данные уезжают за пределы Microsoft 365, можно ли отключить функцию без остановки процесса.

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

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

Три уровня соответствия Microsoft: как читать значки без самообмана

Microsoft 365 App Compliance Program предлагает три уровня, и это полезный ориентир, если не превращать его в магический знак качества.

Первый уровень — Publisher Verification, подтверждение издателя. Он помогает связать приложение с проверенной организацией. Это снижает риск столкнуться с полностью анонимным поставщиком, но не рассказывает, насколько хорошо защищен его продукт и инфраструктура.

Второй — Publisher Attestation. Здесь издатель проходит самооценку по более чем 80 факторам риска. Уровень заметно содержательнее простой верификации: поставщик должен заявить, как он работает с безопасностью, данными и разработкой. Но слово «самооценка» здесь принципиально. Microsoft не проводит независимый аудит каждого утверждения в рамках этой ступени. Поэтому аттестацию стоит воспринимать как полезный набор раскрытий, который можно сопоставить с собственными требованиями, а не как гарантию отсутствия уязвимостей.

Третий уровень — Microsoft 365 Certification. Он предполагает ежегодную независимую проверку безопасности и тестирование на проникновение. После одобрения начальных документов для оценки безопасности предусмотрен срок до 60 дней. Для приложений с доступом к чувствительной почте, финансовым данным или персональной информации именно сертификация дает наиболее сильный внешний сигнал из доступных в программе.

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

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

Контроль развертывания: где заканчивается свобода пользователя

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

Здесь помогают два механизма Microsoft 365: групповые политики и централизованное развертывание через Центр администрирования Microsoft 365. Они позволяют ограничить sideloading, то есть установку надстроек вне контролируемого канала, и развертывать одобренные приложения на конкретные группы пользователей.

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

У такого процесса должно быть несколько шагов:

1. Собрать инвентаризацию. Не только список приложений из центра администрирования, но и фактические расширения, которыми пользуются ключевые команды. Иногда именно «маленькая» надстройка в Excel держит на себе еженедельный отчет.

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

3. Проверить манифест и внешние адреса. Зафиксировать URL, владельца домена, тип хостинга, версию и дату последнего пересмотра. Это основа для обнаружения смены инфраструктуры, а не бюрократическая карточка ради карточки.

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

5. Планировать переоценку. После обновления манифеста, смены владельца продукта, расширения разрешений или появления нового домена надстройка возвращается на рассмотрение. Риск меняется вместе с продуктом.

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

Метод, который не мешает работе

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

Но удобство не должно маскировать устройство продукта. За знакомой кнопкой в Word или Outlook может стоять удаленный веб-контент, доменная инфраструктура поставщика и доступ, который пользователь одобрил один раз и давно забыл.

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

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