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