К статье
Практический материал

Администрирование · 11 мин

Как защищена передача данных через 1С:Линк

Разбираем, как защищена передача данных через 1С:Линк: TLS-шифрование, токены доступа, разграничение прав, аудит подключений и безопасная настройка сервиса.

1С:Линк — сервис фирмы «1С», который позволяет публиковать информационные базы для доступа через интернет без организации собственных VPN, проброса портов и покупки статических IP-адресов. Поскольку через сервис проходят учётные данные — проводки, остатки, персональные данные сотрудников, — вопрос защиты канала передачи принципиален для бухгалтеров, руководителей и администраторов.

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

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

Как устроена передача данных в 1С:Линк

Ключевой элемент схемы — агент 1С:Линк (1c-link-agent), который устанавливается на компьютере с информационной базой или на сервере 1С. Агент не ждёт входящих подключений из интернета, а сам инициирует соединение с серверами сервиса. За счёт этого база остаётся недоступной для прямого обращения извне: сканеры портов и боты, перебирающие открытые веб-серверы, её просто не видят.

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

Такое построение отличает 1С:Линк от самодельных схем «пробросить порт на роутере и опубликовать веб-сервер», где ответственность за сертификаты, обновления и защиту от атак целиком ложится на владельца базы.

Шифрование трафика: что происходит с данными в пути

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

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

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

Аутентификация: кто и как попадает в базу

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

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

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

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

Разграничение прав внутри конфигурации

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

Практический вывод: перед публикацией базы через 1С:Линк стоит пересмотреть роли. Типичная ситуация — пользователю, которому удалённо нужно только вводить первичные документы, исторически назначены «Полные права». При локальной работе это было некритично, но при доступе из интернета избыточные права становятся реальным риском: компрометация одной учётной записи открывает всю базу.

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

Типичные ошибки
01
Выдача полных прав всем удалённым пользователям — компрометация одного пароля открывает всю базу.
02
Общие учётные записи на несколько сотрудников — невозможно установить, кто выполнил операцию, и точечно отключить доступ.
03
Пустые или простые пароли в базе — подбор пароля становится вопросом времени.
04
Неотключённые учётные записи уволенных сотрудников — доступ сохраняется после ухода человека из компании.
05
Публикация тестовых копий баз с реальными данными без необходимости.

Контроль и аудит подключений

Регулярный контроль — обязательная часть эксплуатации. Администратору доступны сведения о настроенных публикациях и пользователях, которым предоставлен доступ; этот список стоит пересматривать периодически, а не только при инцидентах.

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

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

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

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

Список активных пользователей базы
Норма

Каждой учётной записи соответствует действующий сотрудник

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

Есть записи уволенных сотрудников или непонятные логины

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

Входы только под известными учётными записями в рабочее время

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

Массовые неудачные попытки входа или входы в нерабочее время

Назначенные роли
Норма

У каждого пользователя минимально необходимый набор прав

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

У рядовых пользователей полные права

Список публикаций в сервисе
Норма

Опубликованы только реально используемые базы

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

Висят тестовые или забытые публикации

Что 1С:Линк не защищает: зона ответственности клиента

Сервис закрывает транспортный уровень и первичную аутентификацию, но значительная часть рисков остаётся на стороне клиента. Это защита конечных устройств, качество паролей, корректность ролей, своевременное отключение доступов и резервное копирование данных.

Отдельно стоит сказать о резервных копиях: 1С:Линк — это сервис доступа, а не сервис бэкапа. Ответственность за регулярное создание и проверку восстановления резервных копий базы несёт владелец. Шифрованный канал не спасёт от случайного удаления данных, порчи базы или программы-вымогателя на локальном сервере.

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

Альтернативы и когда они оправданны

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

ВариантКому подходитОсновное ограничение
1С:ЛинкНебольшие компании без выделенного администратораЗависимость от доступности внешнего сервиса
VPN + RDP/тонкий клиентКомпании с собственной сетевой инфраструктуройНужны настройка и сопровождение VPN, статический IP или его аналог
Собственный веб-сервер с публикацией базыОрганизации с квалифицированным администраторомПолная ответственность за сертификаты, обновления и защиту от атак
1С:Фреш (облако)Компании, готовые разместить данные у оператораДанные хранятся в инфраструктуре провайдера, действуют ограничения сервиса

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

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

1С:Линк

Быстрое подключение без открытия портов; подходит малым компаниям. Ограничение — зависимость от внешнего сервиса.

Собственный VPN

Полный контроль над инфраструктурой; требует администратора и постоянного сопровождения.

Собственный веб-сервер

Максимальная гибкость публикации; вся ответственность за TLS, патчи и защиту — на владельце.

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

Передаются ли данные через 1С:Линк в открытом виде?

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

Нужно ли открывать порты на роутере для работы 1С:Линк?

Нет. Агент 1С:Линк сам устанавливает исходящее соединение с сервисом, поэтому входящие порты открывать не требуется. Это одно из ключевых преимуществ схемы: база остаётся невидимой для прямых обращений из интернета.

Достаточно ли защиты сервиса, чтобы не настраивать права в базе?

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

Что делать при подозрении на несанкционированный доступ?

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

Заменяет ли 1С:Линк резервное копирование?

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

Безопасно ли работать через 1С:Линк из публичного Wi-Fi?

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

Итог

Что важно запомнить

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