Я бы рекомендовал историю с VPN. Если данные настолько критичные, а судя по всему это так, то по хорошему вам сразу надо это прятать. 1С "голой жопой" наружу, без ежедневного анализа логов, трафика, тестирования веб сервисов с новыми релизами конфы\платформы, это к скорой беде. Найти "дырочку" в открытом наружу приложении всегда можно при желании. Из вышесказанного вопрос - реально ли это поддерживать на таком уровне?

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

Таким образом вы сохраните приватность и останетесь нат"вендорском" стеке без костыликов. А там глядишь шина появится и вопросы эти решит.

Из дельных решений VPN можно взять wireguard там правда нет 2FA уровня сейчас, зато есть очень неплохие клиенты для android и ios. Можно конечно по старинке openvpn, или проприетарные решения (cisco и т.д.)

P.S. вам посоветовали nginx поставить впереди всего, так вот кажется что с безопасность и DDOS он вам не поможет, так как это просто удобны и надёжный прокси\балансировщик\отдаватель статики и т.д..
С DDOS вам может помочь запуск фильтрующего прокси на базе CloudFlare например, у которого есть механизмы определения и блокировки, но тут с 1С могут быть нюансы, надо тестировать...

Всё равно непонятно какие проблемы с фильтром-нгинх перед 1С

А о какой дырочке речь в случае с опубликованным наружу веб или хттп-сервисом 1С? Выйти за рамки прав пользователя и кода сервиса не получится.

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

Примеров можно придумать кучу, но факт один - все что смотрит наружу должно ежедневно контролироваться, если оно ценно для организации.

P.S. по роду деятельности я попадаю в "замесы" по разборам ИБ у разных клиентов. И вот каждый раз погружаясь в тему я все меньше доверяю чему либо с маркировкой "безопасно". Тем более нашей любимой "жёлтой". Последнее откровение был Active Directory Golden Ticket у клиента (страшно то что ты годами можешь об этом не знать и защита по факту только одна - административные меры\подходы).

Все-таки про 1С интересовало. Не думаю что там даже гипотетически можно получить что-то больше, чем заложено в коде самого веб-сервиса. И очкование поэтому надуманное. А от ддоса и брута защитит прослойка нгинх или что-нибудь ещё. Апач тоже используют.
Ну или внешние сервисы типа клауд фларе.

Все-таки про 1С интересовало. Не думаю что там даже гипотетически можно получить что-то больше, чем заложено в коде самого веб-сервиса. И очкование поэтому надуманное. А от ддоса и брута защитит прослойка нгинх или что-нибудь ещё. Апач тоже используют.
Ну или внешние сервисы типа клауд фларе.

Вы неправильно понимаете систему: элемент справочника - условно постоянная единица. Она не должна меняться при проведении.

При проведении надо писать в регистры/перезаполнять регистры.

Но если так надо: пишите в подписке или обработчике проведения. Хуже не будет.

в качестве порассуждать с умными людьми) Если при записи одного объекта (документа) необходимо обновить (перезаполнить\записать) несколько других объектов (справочников). Как это делать правильнее\гуманнее\грамотнее? Добавляем подписку на событие "при записи" на документ и потом в этой подписке 1) Сразу обновляем все, что нужно в транзакции записи. 2) Отдельный РС  качестве очереди на обновление и его наполнение в этой подписке 3) План обмена с отключенной авторегистрацией и последующим включением в него ссылки на объект в этой подписке, если ссылка имеет необходимость обновить свои справочники. Соответственно варианты 2 и 3 само обновление справочников выполняют отложенно, по расписанию.

Если транзакционность не нужна и контроль не обязателен, то делал бы отложенно через РС

А узел плана обмена исключаем из-за скорости? Или опасности блокировок?