Стандарты v8std, связанные с информационной безопасностью

Что такое безопасное программное обеспечение по ГОСТ

Статья будет про стандарты v8std, связанные с информационной безопасностью. Когда мы говорим о стандартах и безопасности, сначала нужно определить, что такое безопасное программное обеспечение. Для этого нужно обратиться к национальному стандарту – ГОСТ. В 2016 году вышел ГОСТ, в котором безопасное программное обеспечение определено как программное обеспечение, разработанное с использованием совокупности мер, направленных на предотвращение проявления и устранение уязвимостей системы. Здесь главное – слово «уязвимости».

Уязвимости (2016) – это недостаток программы, который может быть использован для

реализации угроз безопасности информации.

В 2024 году вышло обновление этого ГОСТ. Определение изменилось: программное обеспечение, разработанное в ходе реализации совокупности мер, направленных на предотвращение, появление и устранение недостатков программы.

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

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

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

Если же мы смотрим на определение через недостатки, то главное – акцент на стадии проектирования или реализации программы. Это означает, что важен процесс разработки – то, что в мировом сообществе называется Software Lifecycle.

Инструменты обеспечения безопасности на этапе разработки

Для описания безопасных процессов разработки используется подход DevSecOps. Существующие методологии сводятся к описанию Secure Software Development Lifecycle (SSDLC). Этот подход представляет подключение специалистов по безопасности на каждом этапе разработки программного обеспечения: при анализе требований, планировании и построении архитектуры. Для нас, как разработчиков, самое важное – на этапе разработки, непрерывной интеграции, тестирования и деплоймента.

Если внимательно посмотреть на процесс разработки, мы можем использовать два инструмента. Первый – SAST (Static Application Security Testing). Это инструмент, который позволяет выполнять статический анализ кода для нахождения проблем безопасности.

Второй инструмент – SCA (Software Composition Analysis). Он позволяет анализировать зависимости, используемые в программном обеспечении, от библиотек, и выстраивать цепочку проблем. Если проблема есть в библиотеке, то она будет унаследована программным обеспечением.

Что такое статический анализ? В 2024 году вышел национальный стандарт ГОСТ, который вводит четкое определение статического анализа – это вид работ по инструментальному исследованию программы, основанный на анализе исходных кодов. Есть ли в 1С статический анализ? Да.

Существует инструмент – автоматическая проверка конфигурации (АПК). Это старая обычная форма, но у нее большая база проверок, которые можно выполнять с помощью этого инструмента.

Второй инструмент – открытый плагин, опубликованный на GitHub и включенный в поставку EDT. Если скачать EDT сейчас, он уже будет предустановлен. Это EDT v8-code-style.

Все разработчики, которые занимаются 1С, знают BSL Language Server – инструмент от Никиты Федькина и Алексея Соснового. В нем также содержится большой набор диагностик, включая диагностики, связанные со стандартами безопасности.

Классификация ошибок информационной безопасности

Чтобы говорить об ошибках, связанных с информационной безопасностью, нужно ввести классификацию: какие ошибки считаем важными, а какие нет. Для этого можно обратиться к ГОСТ 71207-2024.

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

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

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

Есть общая база, каталог CWE – Common Weakness Enumeration, разработанный MITRE, который стандартизирует и классифицирует проблемы безопасности. Подход основан на том, что 80% взломов связаны с уже известными проблемами. CWE помогает исследовать эти проблемы, чтобы не допускать их повторно. Он используется в таких стандартах, как OWASP, NIST, PCI DSS.

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

#std678 Безопасность прикладного программного интерфейса сервера

Общие вопросы безопасности описаны с помощью семейства стандартов, которые мы рассмотрим подробно.

Первый стандарт – #std678 Безопасность прикладного программного интерфейса сервера.

• п.1.1 Несанкционированный вызов серверного кода конфигурации с клиента.

• п.1.2 Не размещайте в серверных процедурах и функциях модулей форм бизнес-логику. Там должен быть только код клиент-серверного взаимодействия и работы с реквизитами формы.

• п.1.3 Контролируйте установку привилегированного режима #std485

• п.2 Ограничьте проникновение небезопасного внешнего кода на сервер #std669

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

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

Ограничение проникновения небезопасного внешнего кода на сервер будет рассмотрено позже.

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

Подробный доклад, посвященный этому стандарту, был на Инфостарте в 2022 году – Владимир Бондаревский «Небезопасный прикладной программный интерфейс»: https://youtu.be/JmsM9WAnkoM?si=5cur09bJOqVfbu5Q

#std679 Ограничение на установку признака «Вызов сервера» у общих модулей

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

• п.2.1 В управляемом режиме работа с Entity объектами (СправочникОбъект, ДокументОбъект и т.д.) выполняется только на сервере.

• п.2.2 Если не планируется поддержка толстого клиента, отключите правила проверки кода для толстого клиента.

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

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

#std740 Безопасное хранение паролей

• п.1 Данные аутентификации иногда приходится запрашивать

• п.2 Не следует хранить пароли и другую конфиденциальную информацию в информационной базе. Файловые инфобазы самые незащищенные.

• п.3 Хранилище паролей используйте когда: Запрашивать пароль на каждую операцию неудобно. Временное сохранение на клиенте может быть не достаточно. Иногда действие надо выполнить на сервере в сеансе без пользователя.

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

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

п 3.1 Не храните пароли и конфиденциальную информацию в реквизитов объектах объектов метаданных, с которыми они связаны.

п 3.2 При использовании 1С:БСП используйте хранилище паролей.

ОбщегоНазначения:

• ЗаписатьДанныеВБезопасноеХранилище

• ПрочитатьДанныеИзБезопасногоХранилища

• УдалитьДанныеИзБезопасногоХранилища

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

п 3.3 Не храните пароли в реквизитах формы.

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

Если требуется взаимодействовать с паролем, извлекать его нужно непосредственно из хранилища на сервере в момент, когда он востребован.

В статических анализаторах существуют проверки. В АПК есть три проверки, которые показывают нарушения, связанные с хранением паролей:

• АПК#339 Чтение пароля из базы данных в реквизит формы может быть небезопасной

• АПК#340 Запись пароля в базу данных из реквизита формы может быть небезопасной

• АПК#345 Небезопасное хранение паролей в информационной базе

В EDT есть проверка, которая показывает небезопасное хранение паролей – EDT#unsafe-password-ib-storage Небезопасное хранение паролей в информационной базе.

Проверка, связанная с записью пароля из реквизита, пока не реализована, но запланирована – EDT#issue411 Open Запись пароля в базу данных из реквизита формы может быть небезопасной.

Все эти проверки связаны с соответствующими CWE-категориями:

• CWE-256: ('Plaintext Storage of a Password')

• CWE-257: ('Storing Passwords in a Recoverable Format')

• CWE-319: ('Cleartext Transmission of Sensitive Information')

История угрозы и механизмы защиты платформы

#std669 Ограничение на выполнение «внешнего» кода

В июне 2016 года произошла громкая история: Dr.Web обнаружил троян, написанный на языке 1С. Его назвали 1С.Drop.1. Пользователям приходило письмо с просьбой обновить адресный классификатор. Когда они запускали внешнюю обработку, происходила рассылка всем контрагентам этого же письма, после чего база данных зашифровывалась.

Соответствующий CWE – CWE-829: (Inclusion of Functionality from Untrusted Control Sphere).

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

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

Платформа запрещает все операции, которые считает опасными:

Механизмы COM:

• COMОбъект();

• ПолучитьCOMОбъект();

• ОболочкаHTMLДокумента.ПолучитьCOMОбъект().

Загрузка внешних компонентов:

• ЗагрузитьВнешнююКомпоненту();

• ПодключитьВнешнююКомпоненту().

Доступ к файловой системе:

• ЗначениеВФайл();

• КопироватьФайл();

• ОбъединитьФайлы();

• ПереместитьФайл();

• РазделитьФайл();

• СоздатьКаталог();

• УдалитьФайлы();

• Новый Файл;

• Новый xBase;

• ЗаписьHTML.ОткрытьФайл();

• ЧтениеHTML.ОткрытьФайл();

• ЧтениеXML.ОткрытьФайл();

• ЗаписьXML.ОткрытьФайл();

• ЧтениеFastInfoset.ОткрытьФайл();

• ЗаписьFastInfoset.ОткрытьФайл();

• КаноническаяЗаписьXML.ОткрытьФайл();

• ПреобразованиеXSL.ЗагрузитьИзФайла();

• ЗаписьZipФайла.Открыть();

• ЗаписьФайлаАрхива.Открыть();

• ЧтениеZipФайла.Открыть();

• ЧтениеФайлаАрхива.Открыть();

• Новый ЧтениеТекста(), если первый параметр ? строка;

• ЧтениеТекста.Открыть(), если первый параметр ? строка;

• Новый ЗаписьТекста(), если первый параметр ? строка;

• ЗаписьТекста.Открыть(), если первый параметр ? строка;

• Новый ИзвлечениеТекста();

• Изменение свойства ИзвлечениеТекста.ИмяФайла;

• ИзвлечениеТекста.Записать();

• Новый Картинка(), если первый параметр ? строка;

• Картинка.Записать();

• Новый ДвоичныеДанные();

• ДвоичныеДанные.Записать();

• Новый ЗаписьДанных(), если первый параметр ? строка;

• Новый ЧтениеДанных(), есть первый параметр ? строка;

• Все методы объекта МенеджерФайловыхПотоков;

• Новый ФайловыйПоток();

• ФорматированныйДокумент.Записать();

• ГеографическаяСхема.Прочитать();

• ГеографическаяСхема.Записать();

• ГеографическаяСхема.Напечатать();

• ТабличныйДокумент.Прочитать();

• ТабличныйДокумент.Записать();

• ТабличныйДокумент.Напечатать();

• ГрафическаяСхема.Прочитать();

• ГрафическаяСхема.Записать();

• ГрафическаяСхема.Напечатать();

• ТекстовыйДокумент.Прочитать();

• ТекстовыйДокумент.Записать().

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

Также блокируются все протоколы и доступ в интернет, которые в безопасном режиме вызывают исключения:

Доступ к Интернету:

• Новый ИнтернетСоединение,

• Новый ИнтернетПочта,

• Новый ИнтернетПрокси,

• Новый HTTPСоединение,

• Новый FTPСоединение.

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

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

Механизм защиты от опасных действий

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

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

Этот механизм можно отключить, и существует много статей, где описано, как это сделать. Отключать его бездумно – самое плохое решение:

• Отключить его можно в настройках конкретного пользователя, сняв соответствующий флажок.

• Можно передать параметр в фабрику «Создать» или «Подключить» при создании внешних обработок, чтобы обработка создалась без дополнительных запросов пользователю.

• В файле conf.cfg есть параметр DisableUnsafeActionProtection, который также отключает этот механизм.

• Свойство расширения ЗащитаОтОпасныхДействий тоже позволяют его отключить.

Если вы хотите отключить этот механизм, убедитесь, что код, который вы запускаете, действительно проверен и безопасен. Никогда не отключайте этот механизм только потому, что он мешает.

#std669 Ограничение на выполнение внешнего кода

#std669 Ограничение на выполнение внешнего кодa – стандарт, который использует механизмы защиты для обеспечения безопасности системы.

• п.1 Запрещено выполнение в небезопасном режиме любого кода на сервере 1С:Предприятия

• п.2 Для всех категорий пользователей должна быть отключена возможность интерактивно открывать внешние отчеты и обработки через Файл ? Открыть

• п.3 Предупреждать администраторов об опасности перед подключением любого внешнего кода

• п.4 Средства обновления должны быть доступны только администраторам

• п.5 даже если произвольный файл разрешено загрузить и хранить, его должно быть запрещено открывать

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

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

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

Средства обновления также должны быть доступны только администраторам. Если в системе хранится произвольный файл, ему должно быть запрещено открываться без проверки. Минимум – проверка на уровне расширения. Этому соответствует CWE-434 Unrestricted Upload of File with Dangerous Type, который указывает, что файлы определенных типов открывать опасно. Не делайте так.

Безопасность при работе с внешними компонентами

Что касается внешних компонентов, то все внешние компоненты всегда считаются опасными. Исходных кодов нет, они скомпилированы, поэтому требования доверия к ним повышены. Не подключайте внешние компоненты из файловой системы. Если вы разработчик внешних компонент, удобно подключать компоненту из файла, указав путь к DLL, но в продуктовом контуре так делать нельзя. DLL можно подменить при запуске, и подключится неизвестная внешняя компонента.

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

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

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

#std770 Ограничения на использование Выполнить и Вычислить на сервере

При разработке решений следует учитывать, что опасно использовать не только непосредственное выполнение алгоритмов методами «Выполнить» и «Вычислить», потому что любой код, который там будет выполнен, может принести вред системе. Соответствующий CWE-94 как раз и называется Code Injection. Код, который вы получили от пользователя, выполнять опасно.

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

Все правила, связанные с безопасным режимом и использованием «Выполнить» и «Вычислить», в АПК реализованы множеством различных проверок:

• АПК#486 Отсутствует включение безопасного режима перед вызовом метода "Выполнить" или "Вычислить"

• АПК#487 Обнаружен вызов метода "Выполнить" вместо "ОбщегоНазначения.ВыполнитьВБезопасномРежиме()

• АПК#488 Обнаружен вызов метода "Вычислить" вместо "ОбщегоНазначения.ВычислитьВБезопасномРежиме()"

• АПК#489 Обнаружен вызов метода "Выполнить" вместо "РаботаВБезопасномРежиме.ВыполнитьВБезопасномРежиме()"

• АПК#490 Обнаружен вызов метода "Вычислить" вместо "РаботаВБезопасномРежиме.ВычислитьВБезопасномРежиме()"

Кроме этого, в EDT есть две запланированные и одна реализованная проверка:

• EDT#641 Open Обнаружен вызов метода "Вычислить" вместо "ОбщегоНазначения.ВычислитьВБезопасномРежиме()".

• EDT#640 Open Обнаружен вызов метода "Выполнить" вместо "ОбщегоНазначения.ВыполнитьВБезопасномРежиме()".

• EDT#server-execution-safe-mode Отсутствует включение безопасного режима перед вызовом метода "Выполнить" или "Вычислить".

В BSL LS также есть две проверки, которые помогают выявлять эти проблемы:

• BSLLS#ExecuteExternalCode.

• BSLLS#ExecuteExternalCodeInCommonModule Ограничения на использование Выполнить и Вычислить на сервере

#std774 Безопасность запуска приложений

Следующая большая проблема связана с запуском приложений. В общем случае это называется OS Command Injection. Когда мы запускаем программу, в строку запуска внешней программы или CMD можно подставить дополнительные данные, которые исполнятся вместе с тем, что задумал разработчик.

Запускать программы можно разными способами:

• КомандаСистемы(<СтрокаКоманды>, <ТекущийКаталог>)

• ЗапуститьПриложение(<СтрокаКоманды>, <ТекущийКаталог>, <ДождатьсяЗавершения>, <КодВозврата>) ;

• НачатьЗапускПриложения(<ОписаниеОповещения>, <СтрокаКоманды>, <ТекущийКаталог>, <ДождатьсяЗавершения>);

• ПерейтиПоНавигационнойСсылке(<НавигационнаяСсылка>);

• Использование COM объектов "Wscript.Shell" и "Shell.Application".

Опасными считаются такие командные строки, которые содержат символы "$", "`", "|", "||" ";", "&", "&&". Они позволяют дописать в строку запуска что-то, что будет интерпретировано иначе, чем задумано. Поэтому сначала нужно проверить, есть ли такие символы, и как от них защититься.

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

Эта обертка упрощает жизнь разработчику. Если мы используем ее в простом режиме и передаем уже сформированную строку запуска, она проверяет наличие запрещенных символов и блокирует запуск, считая его небезопасным. Обертка предоставляет конструктор, который позволяет формировать командные строки через массивы – как в современных языках, например JavaScript и Python. При сборке строки конструктор корректно расставляет кавычки и делает опасные символы безопасными.

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

В EDT проверка запланирована, но не реализована – EDT#418 Open Небезопасный запуск приложения.

В АПК реализованы две проверки, которые помогают выявлять нарушения, связанные с безопасным запуском приложений:

• АПК#534 Небезопасный запуск приложения.

• АПК#1425 Предположительно, создается временный исполняемый файл с переменным именем.

#std775 Безопасность программного обеспечения, вызываемого через открытые интерфейсы

Следующая проверка – стандарт безопасности запуска открытых интерфейсов. Приложения вроде Microsoft Word, Excel и другие позволяют содержать внутри файла исполняемый код, например макросы. При работе с COM-объектами таких файлов исполнение макросов может происходить автоматически.

Это означает, что при открытии файлов через COM-объекты Word или Excel нужно предварительно установить запрет на исполнение макросов, потому что мы не знаем, что находится в файле, и исполнять его на сервере запрещено.

Эти проверки реализованы в АПК:

• АПК#536 Отсутствует отключение макросов при работе с документом Microsoft Word

• АПК#537 Отсутствует отключение макросов при работе с документом Microsoft Excel

И запланированы в EDT, но пока не реализованы – EDT#662 Open Отсутствует отключение макросов при работе с документом Microsoft Word.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAMLEAD&CIO EVENT.