Аутентификация доступа к интернет-ресурсу 1С: что это и как работает

Когда 1С обращается к внешнему интернет-ресурсу — обновляет курсы валют, отправляет отчётность, обменивается данными с сайтом или обращается к веб-сервису, — удалённый сервер требует подтвердить личность клиента. Этот процесс и называется аутентификацией: программа передаёт учётные данные, сервер проверяет их и либо открывает доступ, либо возвращает ошибку. Для пользователя это чаще всего выглядит как сообщение «Ошибка аутентификации», «401 Unauthorized» или диалог с запросом логина и пароля.

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

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

Где в 1С встречается аутентификация интернет-ресурсов

Наиболее типичный сценарий — обмен с сайтом интернет-магазина. Конфигурации «Управление торговлей» и «1С:Комплексная автоматизация» выгружают товары и загружают заказы через HTTP-запросы, и сайт требует логин и пароль, указанные в настройках обмена. Если пароль на сайте сменили, а в 1С не обновили, обмен останавливается с ошибкой аутентификации.

Второй распространённый случай — обращение к веб-сервисам: проверка контрагентов, получение курсов валют, сервисы ФНС и операторов ЭДО, сервисы «1С:Контрагент» и «1С:Обновление программ». Для них используются либо логин и пароль от портала 1С, либо ключи API. Третий сценарий — работа через FTP при выгрузке файлов и подключение к почтовым серверам для отправки писем из учётной системы.

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

Какие методы аутентификации используются

Базовая (Basic) аутентификация — самый простой метод: логин и пароль передаются в заголовке HTTP-запроса в кодированном виде. Он применяется в типовых обменах с сайтами на «1С-Битрикс» и во многих веб-сервисах. Метод безопасен только в сочетании с HTTPS: без шифрования канала учётные данные можно перехватить.

Аутентификация по токену или API-ключу используется в современных REST-сервисах: вместо пароля программа передаёт выданный сервисом ключ. Токены имеют срок действия — его истечение выглядит как внезапная ошибка доступа, хотя логин и пароль не менялись. Метод NTLM (Windows-аутентификация) встречается при доступе к корпоративным ресурсам и прокси: используются доменные учётные данные текущего пользователя.

Наконец, доступ к ресурсам 1С, опубликованным на веб-сервере (тонкий клиент через браузер, веб-сервисы самой базы), может защищаться аутентификацией средствами веб-сервера IIS или Apache. В этом случае окно запроса логина и пароля показывает браузер ещё до запуска интерфейса 1С.

Сравнение методов

Basic (логин и пароль)

Простая настройка, подходит для обмена с сайтом. Обязательно использовать только по HTTPS.

Токен / API-ключ

Подходит для REST-сервисов и интеграций. Ограничение: токен истекает и требует перевыпуска.

NTLM (доменная)

Удобна в корпоративной сети с Active Directory. Не работает за пределами домена и через часть прокси.

Сертификат клиента

Максимальная защита для критичных обменов. Требует выдачи, установки и продления сертификатов.

Как выглядит ошибка и что она означает

Классический признак — сообщение «Ошибка аутентификации. Доступ запрещён» или код HTTP 401 в журнале обмена. При обмене с сайтом в журнале регистрации фиксируется ответ сервера с текстом вида «401 Unauthorized». Если 1С работает через браузер, появляется стандартное окно веб-сервера с полями «Имя пользователя» и «Пароль».

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

Где хранятся и как настраиваются учётные данные

Для обмена с сайтом логин и пароль указываются в настройках узла обмена: в «Управлении торговлей» это раздел «Администрирование» → «Обмен с сайтами», где в карточке настройки заполняются адрес сайта, имя пользователя и пароль. Проверка подключения выполняется кнопкой «Проверить соединение» прямо в форме настройки.

Для сервисов фирмы «1С» (обновление программ, «1С:Контрагент») используются регистрационные данные портала 1С:ИТС. Они вводятся в разделе «Администрирование» → «Интернет-поддержка и сервисы» → «Подключение интернет-поддержки». Пароли к почтовым ящикам задаются в настройках учётных записей электронной почты, параметры FTP — в соответствующих настройках обменов.

Доступ к опубликованной базе через веб-сервер настраивается дважды: список пользователей и их пароли задаются в конфигураторе («Администрирование» → «Пользователи»), а метод проверки подлинности на уровне веб-сервера — в настройках IIS или Apache и в файле публикации. Учётная запись веб-сервера и пользователь базы 1С могут быть связаны, а могут существовать независимо — это зависит от выбранной схемы.

1. 1
   Определите, к какому ресурсу идёт обращение: сайт, веб-сервис, почта, FTP или прокси — по тексту ошибки и журналу регистрации.
2. 2
   Проверьте логин и пароль вручную: войдите на ресурс через браузер с теми же данными.
3. 3
   Если вход через браузер удался — обновите пароль в настройках 1С и повторите операцию.
4. 4
   Если используется токен или API-ключ — проверьте его срок действия и перевыпустите при необходимости.
5. 5
   При коде 407 проверьте настройки прокси: адрес, порт и доменные учётные данные.
6. 6
   Проверьте результат: обмен должен пройти без записей об ошибке в журнале регистрации.

Типичные причины ошибок и их устранение

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

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

Безопасность при работе с учётными данными

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

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

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

Как проверить, что проблема решена

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

Контрольные точки

Как проверить результат

Тестовое соединение с ресурсом

Норма

Сообщение об успешном подключении

Тревожный признак

Повторная ошибка 401 или 407

Журнал регистрации

Норма

Нет новых записей об ошибках аутентификации

Тревожный признак

Ошибки повторяются с той же периодичностью

Фактический обмен данными

Норма

Документы и справочники загружаются и выгружаются

Тревожный признак

Обмен завершается с ошибкой или данные не приходят

Частые вопросы

Чем аутентификация отличается от авторизации?

Аутентификация — проверка, что вы тот, за кого себя выдаёте (логин и пароль верны). Авторизация — определение того, что вам разрешено делать после успешной аутентификации. Сначала сервер проверяет подлинность, затем — права доступа.

Почему ошибка появилась внезапно, хотя ничего не меняли?

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

Что означает код 407 вместо 401?

Код 407 означает, что аутентификацию требует прокси-сервер вашей сети, а не целевой ресурс. Нужно проверить настройки прокси в 1С и доменные учётные данные, а не пароль к сервису.

Где посмотреть, к какому ресурсу обращается 1С при ошибке?

Основной источник — журнал регистрации: в нём видно, какой механизм (обмен с сайтом, веб-сервис, почта) зафиксировал ошибку, и часто указан адрес ресурса. Для обменов также помогают журналы обмена данными в соответствующих разделах конфигурации.

Безопасно ли хранить пароль от сайта в настройках обмена 1С?

Типовые механизмы хранят такие пароли в защищённом виде внутри базы. Риск возникает при записи паролей в открытом виде в доработках и при передаче по незащищённому HTTP. Используйте HTTPS и отдельную техническую учётную запись с минимальными правами.