Защита базы 1С 8.3 паролем и правами доступа

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

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

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

Что именно защищает пароль, а что нет

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

Чего пароль пользователя не делает:

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

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

Файловая и клиент-серверная база: где слабое место

Способ хранения определяет, насколько серьёзной может быть защита. Разница принципиальная.

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

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

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

Как поставить пароль на вход в файловую базу

Самый частый сценарий — закрыть вход в файловую базу . Делается это через список пользователей. Есть два пути, и они приводят к одному результату.

Способ 1. В режиме 1С:Предприятие (для типовых конфигураций).

1. Откройте раздел Администрирование → Настройки пользователей и прав → Пользователи.
2. Нажмите Создать.
3. Заполните имя (это и есть логин), поставьте флажок Вход в программу разрешён.
4. Выберите Аутентификация 1С:Предприятия и задайте пароль. Повторите его в поле подтверждения.
5. Назначьте профиль групп доступа (права) и запишите пользователя.

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

Способ 2. В Конфигураторе (универсальный).

1. Запустите базу в режиме Конфигуратор.
2. Откройте Администрирование → Пользователи.
3. Нажмите Добавить, на вкладке Основные укажите имя и пароль.
4. На вкладке Прочие отметьте доступные роли (как минимум одну) и закройте окно.

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

Политика паролей. Чтобы пароли не были вида 123, задайте требования. В типовых это раздел Администрирование → Настройки пользователей и прав → Настройки входа: минимальная длина, обязательная сложность, срок действия пароля. Названия пунктов в разных конфигурациях могут слегка отличаться, но блок настроек входа есть почти всегда.

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

Роли и права доступа: кто что видит

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

Роль — это объект конфигурации, набор прав на справочники, документы, отчёты и действия (чтение, добавление, изменение, удаление, проведение). В дереве конфигурации роли лежат в ветке Общие → Роли. Там же, в правах конкретной роли, можно включить ограничения на уровне записей (RLS) — например, чтобы менеджер видел только свои документы.

На практике в типовых конфигурациях роли почти не раздают вручную. Вместо этого работают с группами доступа:

• Профили групп доступа — готовые наборы ролей под должность (Бухгалтер, Кладовщик, Расчётчик зарплаты и т. д.).
• Группы доступа — связывают профиль с конкретными пользователями.

Логика простая: завели сотрудника → включили в нужную группу доступа → он получил только те права, что входят в профиль. Пути: Администрирование → Настройки пользователей и прав → Профили групп доступа и → Группы доступа.

Несколько правил, которые экономят нервы:

• 🧩 давайте минимально необходимые права, а не «на всякий случай» все;
• 🧩 полные права — только тем, кто реально администрирует базу;
• 🧩 для временного сотрудника заводите отдельную учётную запись, а не общую;
• 🧩 уволенному сразу снимайте флажок Вход в программу разрешён, а не удаляйте запись — так сохранится история его действий.

Защита конфигурации от изменений

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

Для типовых конфигураций главный инструмент — режим поддержки. Он включён по умолчанию и запрещает редактировать объекты, которые поставляет вендор, чтобы не сломать будущие обновления. Проверить и настроить его можно в Конфигураторе: Конфигурация → Поддержка → Настройка поддержки. Пока стоит «Конфигурация находится на поддержке» с запретом изменений, случайно переписать типовой код не выйдет.

Что ещё помогает закрыть прикладное решение от вмешательства:

• Право на изменение конфигурации выдавайте только администраторам. Если у роли нет административных прав, Конфигуратор для такого пользователя будет доступен лишь на просмотр.
• При передаче собственной доработки сторонним людям модули можно поставить на защиту от просмотра — это делается при формировании файлов поставки через Конфигурация → Поставка конфигурации. Пароль поставки закрывает исходный код от чтения.
• На уровне платформы работает «Защита от опасных действий» — предупреждение, когда внешний отчёт или обработка пытаются выполнить потенциально рискованный код. Отключать её без причины не стоит.

Блокировка сеансов и монопольный режим

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

В Конфигураторе это Администрирование → Блокировка установки соединений с информационной базой: задаёте период блокировки, текст сообщения для пользователей и код разрешения. Код разрешения — это пароль, который позволит вам самому зайти в заблокированную базу (передаётся параметром запуска /UC). В типовых конфигурациях похожая возможность есть в режиме предприятия, в разделе обслуживания — там это называется блокировкой работы пользователей.

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

• обновление конфигурации базы данных, если оно меняет структуру таблиц;
• загрузка информационной базы из файла .dt;
• тестирование и исправление информационной базы;
• выгрузка базы в файл .dt.

Если при такой операции в базе есть активные сеансы, платформа попросит их завершить. Посмотреть, кто сейчас работает, можно в Администрирование → Активные пользователи.

Для клиент-серверной базы администратор управляет сеансами и через консоль администрирования, и из командной строки утилитой rac (например, rac session list). Конкретные подкоманды и параметры смотрите в справке rac help — выдумывать их не нужно.

Безопасность на уровне операционной системы и сети

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

Для файловой базы:

• 🔐 ограничьте права NTFS на папку с базой — доступ только нужным учётным записям, а не группе «Все»;
• 🔐 не держите рабочую базу в папках, которые синхронизируются с облаком (это и риск утечки, и источник повреждений файла);
• 🔐 включите шифрование диска (BitLocker или аналог) на компьютере, где лежит база и бэкапы;
• 🔐 защитите паролем саму учётную запись Windows и настройте автоблокировку экрана.

Для клиент-серверной базы:

• 🔐 установите пароль администратора кластера 1С, чтобы посторонний не управлял базами через консоль;
• 🔐 для подключения 1С к СУБД используйте отдельную учётную запись с минимально нужными правами, а не администратора СУБД;
• 🔐 закройте фаерволом доступ к портам сервера 1С и СУБД извне, оставив только нужные адреса;
• 🔐 удалённый доступ организуйте через VPN, а не прямой проброс портов в интернет.

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

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