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

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

Где хранятся учетные данные бизнес-приложения в системе 1С:Предприятие

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

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

Важно сразу разделить три разных типа «учетных данных»: пароли пользователей информационной базы, параметры подключения к серверу 1С и СУБД, а также служебные секреты (например, пароли кластера серверов и хранимые пароли к внешним ресурсам). Хранятся они по-разному, и путать их — частая причина ошибок при администрировании.

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

Какие учетные данные вообще существуют в 1С

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

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

Где хранятся пароли пользователей информационной базы

Учетные записи пользователей — имена, роли, настройки аутентификации и хеши паролей — являются частью информационной базы. В файловом режиме они находятся внутри файла 1Cv8.1CD в каталоге базы. В клиент-серверном режиме те же сведения лежат в системных таблицах базы данных на стороне СУБД (MS SQL Server, PostgreSQL, Oracle или IBM DB2).

Платформа не сохраняет пароль в открытом или обратимо зашифрованном виде: хранится хеш, вычисленный с использованием криптографического алгоритма. Это означает две практические вещи. Во-первых, «посмотреть» забытый пароль нельзя даже с полным доступом к файлу базы — можно только сбросить его и задать новый. Во-вторых, любые программы, обещающие «восстановить пароль из 1Cv8.1CD», либо подбирают его перебором, либо вводят в заблуждение.

Управление учетными записями выполняется штатно: в конфигураторе через меню «Администрирование — Пользователи» или в пользовательском режиме через раздел администрирования (в типовых конфигурациях — «Настройки пользователей и прав»). Там же задаются требования к сложности паролей и ограничения на вход.

Списки баз и параметры подключения на клиенте

На компьютере пользователя платформа хранит не пароли к базе, а список информационных баз и параметры их подключения. Основной файл — ibases.v8i, который обычно располагается в профиле пользователя: %APPDATA%\1C\1CEStart\ibases.v8i (в типичной установке Windows). Это текстовый файл, где для каждой базы указаны имя, тип подключения, путь к файлу или адрес сервера и имя базы на сервере.

Общие настройки стартера (версии по умолчанию, каталоги шаблонов, общие списки баз) могут дополнительно задаваться в файле 1cestart.cfg — в каталоге установки платформы или в профиле пользователя. Если в инфраструктуре используется общий список баз для всех сотрудников, он обычно публикуется именно через этот механизм.

Пароли пользователей в этих файлах не сохраняются: при старте сеанса платформа запрашивает их интерактивно либо использует аутентификацию операционной системы. Если в окне запуска база открывается без запроса логина — скорее всего, включена доменная (OS) аутентификация, и «учетные данные» в этом случае предоставляет Windows.

text
%APPDATA%\1C\1CEStart\ibases.v8i  — список баз пользователя
%APPDATA%\1C\1cv8\conf\           — служебные настройки клиента
C:\Program Files\1cv8\<версия>\bin\conf\1cestart.cfg — общие настройки стартера

Учетные данные в клиент-серверном режиме: СУБД и кластер

В клиент-серверной архитектуре появляются два дополнительных хранилища секретов. Первое — реестр кластера серверов 1С: служебные файлы в каталоге srvinfo (путь задаётся при установке сервера, в Windows по умолчанию это подкаталог в Program Files или в каталоге, указанном агентом сервера). Здесь хранятся список баз кластера, параметры их подключения к СУБД, включая имя пользователя СУБД и пароль в защищённом виде, а также сведения об администраторах кластера.

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

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

Пароли к внешним системам внутри прикладного решения

Отдельная категория — секреты, которые сохраняет сама конфигурация: пароли к почтовым ящикам для обмена документами, токены и ключи API для интеграций, данные для подключения к FTP или облачным сервисам. В типовых решениях для этого используется механизм безопасного хранилища (в библиотеке стандартных подсистем — «Безопасное хранилище данных»), который записывает секреты в специальные служебные данные информационной базы.

Такие данные, в отличие от паролей пользователей, хранятся в восстановимом виде — системе нужно реально предъявлять их внешним сервисам. Поэтому они потенциально извлекаемы тому, кто имеет полные права в базе и доступ к встроенному языку. Это нужно учитывать при выдаче ролей «Полные права» и при передаче копий базы сторонним лицам: вместе с копией уходят и интеграционные секреты.

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

Типичные ошибки
01
Искать пароли пользователей в файле ibases.v8i — там хранятся только параметры подключения, паролей в нём нет
02
Пытаться извлечь пароль из 1Cv8.1CD сторонними утилитами — хранится хеш, а такие утилиты часто несут вредоносный код
03
Передавать копию базы подрядчику, не сменив пароли к почте и сервисам ЭДО — интеграционные секреты уходят вместе с копией
04
Использовать одну учетную запись СУБД для всех баз и других приложений — компрометация одной базы открывает доступ ко всем
05
Хранить пароль администратора кластера в текстовых файлах рядом со скриптами бэкапа без ограничения доступа

Как проверить и где посмотреть настройки безопасно

Проверка начинается с определения режима работы базы: откройте список баз в стартере и посмотрите строку подключения — путь к файлу означает файловый режим, пара «сервер/имя базы» — клиент-серверный. Далее действия различаются.

В файловом режиме достаточно убедиться, что доступ к каталогу с файлом 1Cv8.1CD на файловом сервере ограничен только теми, кто должен работать с базой, и что сам каталог не опубликован «на чтение для всех». В клиент-серверном режиме проверьте через консоль кластера, какие базы зарегистрированы, под какой учетной записью СУБД они работают, и задан ли пароль администратора кластера (его отсутствие — распространённая находка при аудите).

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

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

Восстановление доступа и частые сценарии

Забыт пароль пользователя базы

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

Перенос базы на новый сервер

При переносе клиент-серверной базы переносятся данные СУБД (вместе с пользователями ИБ), а вот регистрацию базы в кластере нового сервера и учетную запись СУБД нужно создавать заново. Пароли кластера старого сервера на новый не мигрируют автоматически — администраторов кластера заводят отдельно.

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

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

Вход в базу под обычным пользователем
Норма

Запрашивается логин и пароль либо работает доменная аутентификация

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

Вход происходит без всякой аутентификации у всех пользователей

Пароль администратора кластера
Норма

Консоль кластера запрашивает учетные данные администратора

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

Консоль подключается к кластеру без запроса

Доступ к каталогу файловой базы
Норма

Чтение каталога доступно только рабочей группе пользователей базы

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

Каталог доступен всем пользователям сети

Интеграционные пароли после передачи копии
Норма

Пароли к внешним сервисам сменены, старые не работают

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

С копии базы можно подключиться к почте или ЭДО компании

Итог

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

Пароли пользователей хранятся внутри информационной базы в виде хешей и не подлежат просмотру — только сбросу. Параметры подключения лежат в ibases.v8i на клиенте и в реестре кластера srvinfo на сервере, а пароль СУБД защищается средствами СУБД. Главные риски — открытый доступ к файлам базы, пустой пароль кластера и интеграционные секреты, уходящие вместе с копиями базы.

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

Можно ли посмотреть пароль пользователя 1С, если есть доступ к файлу базы?

Нет. Платформа хранит только хеш пароля, обратное восстановление невозможно. Даже с полным доступом к файлу 1Cv8.1CD или таблицам СУБД пароль можно лишь сбросить и задать новый через штатные средства администрирования.

Где лежит список информационных баз на компьютере пользователя?

В файле ibases.v8i в профиле пользователя, обычно по пути %APPDATA%\1C\1CEStart. Это текстовый файл, его можно открыть блокнотом. Паролей в нём нет — только имена баз и параметры подключения.

Чем отличается пароль пользователя базы от пароля администратора кластера?

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

Переносятся ли пользователи при выгрузке базы в файл DT?

Да, учетные записи пользователей с их настройками и хешами паролей сохраняются в выгрузке и восстанавливаются при загрузке. Учитывайте это, передавая DT-файл третьим лицам: логины и структура прав остаются видимыми.

Что делать, если кластер серверов пускает без пароля администратора?

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

Безопасно ли хранить пароли к почте и ЭДО в настройках конфигурации?

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