Как пройти аудит в 1С:Фреш для расширения при отправке почты?

При адаптации доработок под работу в сервисе «1С:Предприятие через Интернет» (1С:Фреш) разработчики регулярно сталкиваются со строгими правилами проверки безопасности. Одно из наиболее частых требований аудиторов связано с контролем сетевых подключений и предотвращением несанкционированной утечки данных во внешнюю среду.

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

В чем отличие расширений от внешних обработок при запросе разрешений

Проанализируем архитектуру изоляции кода. Для внешних отчетов и обработок в БСП предусмотрен стандартный программный интерфейс: в модуле объекта объявляется экспортная функция СведенияОВнешнейОбработке(), в которой разработчик кодом формирует массив разрешений через менеджер РаботаВБезопасномРежиме.

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

Разрешения на сетевые вызовы для расширения настраиваются не в исходном коде, а административно — обслуживающей организацией (партнером 1С) при загрузке файла расширения в карточку конфигурации сервиса. При регистрации новой версии расширения обслуживающая организация в интерфейсе управления сервисом указывает перечень внешних адресов, портов и протоколов, к которым разрешен доступ. На основании этой карточки кластер серверов автоматически формирует профиль безопасности для сеанса работы расширения.

Типичная ошибка: выбор почтового протокола

Выясним причину частой технической ошибки при формировании запроса к почтовым серверам. Нередко разработчики пытаются запросить разрешение на использование протокола IMAP для задач рассылки документов:

// Ошибочный подход для задачи отправки писем:
РаботаВБезопасномРежиме.РазрешениеНаИспользованиеИнтернетРесурса("IMAP", УчетнаяЗапись.АдресСервераIMAP, УчетнаяЗапись.ПортIMAP);

Посмотрим на назначение почтовых протоколов:

1. IMAP (и POP3) предназначен исключительно для чтения входящей корреспонденции и управления папками на сервере.
2. SMTP — единственный протокол платформенного объекта ИнтернетПочта, отвечающий за отправку исходящих писем (обычно используются порты 25, 465 или 587).

Если в карточке расширения указать разрешение для IMAP, а в коде вызывать отправку через SMTP, платформа заблокирует соединение из-за нарушения профиля безопасности, и аудит не будет пройден.

Как поступать, если адреса почтовых серверов заранее неизвестны

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

Регламент аудита сервиса 1С:Фреш выдвигает следующие правила для работы с динамическими внешними ресурсами:

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

Рекомендуемый способ: использование типовых подсистем БСП

Разберем наиболее надежный вариант прохождения аудита — отказ от прямой работы с низкоуровневым объектом ИнтернетПочта в пользу штатных возможностей конфигурации.

В типовых конфигурациях уже встроена подсистема «Работа с электронной почтой». Использование общего модуля РаботаСЭлектроннойПочтой и клиентского модуля РаботаСЭлектроннойПочтойКлиент дает существенные преимущества:

1. Отсутствие претензий аудиторов: отправка через предопределенные механизмы БСП считается безопасной, так как базовые учетные записи уже обладают всеми нужными системными разрешениями.
2. Открытие стандартной формы отправки: сформировав в расширении структуру письма и прикрепив двоичные данные печатной формы, можно открыть типовую форму создания письма. Пользователь визуально видит адрес получателя, тему, вложение и нажимает кнопку отправки. Это полностью исключает подозрения аудита в скрытой выгрузке информации.
3. Кроссплатформенность: обращение к локальным почтовым клиентам операционной системы запрещено регламентом аудита для веб-клиента. Использование модулей БСП обеспечивает одинаковую работу решения как в тонком клиенте, так и в браузере.

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