Как защитить файловую базу 1С от копирования с помощью IIS и ограничения доступа

← На главную

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

Архитектура решения: IIS и права NTFS

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

Чтобы решить эту проблему, переведем работу в режим веб-доступа:

Устанавливаем на локальный ПК или сервер роль веб-сервера IIS.
Публикуем файловую базу 1С на веб-сервере. Пользователи теперь будут подключаться к базе через тонкий клиент по HTTP/HTTPS, а не через сетевой путь.
Переходим к папке, в которой физически лежит файл 1Cv8.1CD, и настраиваем права доступа NTFS.
Забираем абсолютно все права на эту папку у обычных пользователей Windows. Они не должны иметь возможности даже зайти в этот каталог.
Даем полные права (чтение и запись) только служебной учетной записи, под которой работает пул приложений IIS (AppPool Identity).

Таким образом, мы изолируем файл на уровне операционной системы. Процесс IIS (работающий от своего сервисного пользователя) сможет читать и писать в базу, а пользователь, запускающий тонкий клиент 1С, физически не будет видеть папку с базой.

Ограничение доступа внутри платформы 1С

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

1. Внешние обработки и отчеты. Если пользователь имеет право запускать внешние обработки, он может написать или скачать простой скрипт, который программно скопирует файл базы в другую директорию. Так как код обработки выполняется на стороне сервера (в нашем случае от имени пользователя IIS, у которого есть полные права на файл), защита NTFS не сработает. Запретите профилям пользователей право ИнтерактивноеОткрытиеВнешнихОбработок и ИнтерактивноеОткрытиеВнешнихОтчетов.

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

Отключить права на вывод списков.
Запретить сохранение табличных документов.
Ограничить работу с буфером обмена.

Защита системной папки публикации и интерфейсов (OData)

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

Также категорически важно отключить стандартный интерфейс OData (REST API). Если он останется включенным, злоумышленник сможет написать простейший скрипт, который спарсит всю базу без участия тонкого клиента. Пример того, как должен быть отключен этот интерфейс в файле default.vrd:


<?xml version="1.0" encoding="UTF-8"?>
<vrs:point xmlns:vrs="http://v8.1c.ru/8.2/virtual-resource-system"
           base="/MyBase"
           ib="File="D:\1C_Bases\MyBase";">
    <ws pointEnableCommon="false"/>
    <standardOdata enable="false" reuseSessions="autouse" />
</vrs:point>

Защита от физического доступа: шифрование EFS и BitLocker

Выясним причину возможных утечек в ситуации, когда пользователь имеет физический доступ к компьютеру (например, база лежит прямо на его рабочем ПК). Стандартные права NTFS легко обходятся, если загрузиться с установочной флешки Linux или Windows PE, либо просто снять жесткий диск и подключить к другому ПК.

Для надежной защиты применяем шифрование операционной системы:

Используйте полнодисковое шифрование BitLocker, чтобы защитить информацию при краже самого жесткого диска.
Используйте шифрующую файловую систему EFS для папки с базой. Сертификат и ключ шифрования EFS необходимо привязать исключительно к служебной учетной записи IIS. При такой настройке даже локальный администратор не сможет прочитать файл 1Cv8.1CD из-под своей учетной записи.

Защита канала и лицензирование

Обязательно настройте SSL-сертификат на вашем веб-сервере IIS. Если вы используете обычный протокол HTTP, трафик (включая пароли от базы 1С) может быть перехвачен внутри локальной сети с помощью сниффера. Использование HTTPS зашифрует этот канал.

Также обратим внимание на важный технический нюанс лицензирования. При переводе базы в файловый веб-режим меняется схема потребления лицензий. Веб-сервер начинает выдавать программные лицензии по принципу «один сеанс — одна лицензия». Если раньше пользователь мог открыть 3 окна базы 1С на одном ПК с затратой одной аппаратной или программной лицензии, то через IIS каждое новое окно тонкого клиента или браузера будет забирать отдельную лицензию с сервера.

Альтернативное решение: Использование RemoteApp

Если настройка IIS и веб-клиента кажется избыточной, рассмотрим альтернативный вариант для локальной сети — публикацию через службы удаленных рабочих столов (Terminal Server) в режиме RemoteApp.

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