Записки IT специалиста

Публикация информационных баз 1С:Предприятие при помощи веб-сервера - один из популярных сценариев удаленного доступа, удобный тем. что можно работать из любого места и даже без установленного клиента 1С, через браузер. Но при этом остро встает вопрос обеспечения безопасности такого соединения. Для этих целей мы будем использовать SSL-шифрование с бесплатным сертификатом от Let's Encrypt, а для дополнительной защиты подключим аутентификацию средствами веб-сервера.

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

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

Если же вы только начинаете заниматься этим вопросом, то правильно настроить веб-сервер и опубликовать базы вам поможет наша статья:

Публикация баз данных 1С:Предприятие 8.3 на веб-сервере Apache в Debian или Ubuntu
Обновлено: 08.09.2022

Также, для получения бесплатного сертификата вам понадобится доменное имя, получить сертификат на IP-адрес или несуществующий домен нельзя.

Получение бесплатного сертификата Let's Encrypt

На сегодняшний день получение бесплатного сертификата Let's Encrypt является наиболее оптимальным способом для защиты ваших веб-служб. Некоторых пугает кажущаяся сложность данной операции и необходимость продления сертификата каждые 90 дней, но ничего страшного в этом нет. все прекрасно автоматизировано и работает по принципу один раз настроил и забыл.

Прежде всего установим службу для управления сертификатами:

apt install certbot

Затем создадим некоторую инфраструктуру для ее работы:

mkdir /var/www/letsencrypt
chown -R www-data:www-data /var/www/letsencrypt

Затем создадим файл конфигурации для веб-сервера Apache:

nano /etc/apache2/conf-available/le.conf

И поместим в него следующий текст:

Alias /.well-known/acme-challenge/ /var/www/letsencrypt/.well-known/acme-challenge/

<Directory "/var/www/letsencrypt/.well-known/acme-challenge/">
    Options None
    AllowOverride None
    ForceType text/plain
    Require all granted
    RedirectMatch 404 "^(?!/\.well-known/acme-challenge/[\w-]{43}$)"
</Directory>

Затем подключим созданную конфигурацию к Apache:

a2enconf le

Проверим конфигурацию веб-сервера на ошибки и перезапустим его:

apachectl -t
service apache2 restart

Теперь попробуем пробное получение сертификата:

certbot certonly --dry-run --webroot -w /var/www/letsencrypt -d 1с.example.com

где 1с.example.com - используемый нами домен, ключ --dry-run обозначает пробную попытку, без реального получения сертификата. Если все прошло без ошибок получим сертификат по-настоящему:

certbot certonly --webroot -w /var/www/letsencrypt -d 1с.example.com

Если ваш сервер находится внутри периметра, то для нормальной работы certbot вы должны пробросить наружу как 443 порт (HTTPS), так и 80 порт (HTTP).

При установке certbot задания на автоматический запуск продления будут созданы автоматически, ничего делать не нужно. Но потребуется настроить перезапуск веб-сервера после обновления сертификата, для этого откройте конфигурационный файл /etc/letsencrypt/renewal/1с.example.com.conf и добавьте в секцию [renewalparams] строку:

[renewalparams]
...
renew_hook = systemctl reload apache2

Это обеспечит перезапуск Apaсhe после обновления сертификата, если обновления не было, то перезапускаться служба не будет.

Настройка SSL-шифрования на веб-сервере Apache

Сертификат получен, самое время перейти к настройке веб-сервера. Современные реалии диктуют единственный вариант работы: только HTTPS, все запросы по незащищенному протоколу HTTP должны автоматически перенаправляться на HTTPS-версию. При этом не следует делать недоступным HTTP-порт, во-первых, он нужен для работы certbot, во-вторых, это создаст неудобство пользователям, так как просто набрав в адресной строке 1с.example.com они никуда не попадут, пока явно не укажут протокол: https://1с.example.com.

Так как наш веб-сервер, по условиям, обслуживает только публикации 1С, то мы не будем создавать новые виртуальные хосты, а отредактируем те, что по умолчанию. Откроем файл /etc/apache2/sites-available/000-default.conf и приведем его к следующему виду:

<VirtualHost *:80>   
   RewriteEngine On
   RewriteCond %{REQUEST_URI} !^/\.well\-known/acme\-challenge/
   RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]   
   
   ServerAdmin webmaster@example.com
   DocumentRoot /var/www/html   
   ErrorLog ${APACHE_LOG_DIR}/error.log
   CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Конфигурация стандартная и особо в комментариях не нуждается, за исключением первых трех строк, которые осуществляют перенаправление на HTTPS всех HTTP запросов, кроме Let's Encrypt.

Теперь откроем /etc/apache2/sites-available/default-ssl.conf - файл с настройками виртуального хоста с SSL-защитой и внесем в него следующие строки:

<VirtualHost *:443>
   ServerAdmin webmaster@example.com
   DocumentRoot /var/www/html   
   ErrorLog ${APACHE_LOG_DIR}/error_ssl.log
   CustomLog ${APACHE_LOG_DIR}/access_ssl.log combined

   SSLEngine on
   SSLCertificateFile /etc/letsencrypt/live/1с.example.com/cert.pem
   SSLCertificateChainFile /etc/letsencrypt/live/1с.example.com/fullchain.pem
   SSLCertificateKeyFile /etc/letsencrypt/live/1с.example.com/privkey.pem
   SSLCACertificateFile /etc/letsencrypt/live/1с.example.com/chain.pem

   Protocols h2 http/1.1
   Header always set Strict-Transport-Security "max-age=63072000"
</VirtualHost>

Конфигурация, в целом, тоже стандартная. Набор SSL-опций включает шифрование и указывает пути к сертификатам. Последние две строки разрешают протокол HTTP/2, если поддерживается клиентом и включают HSTS, специальный заголовок, который предписывает клиенту, если он уже один раз успешно соединился с сайтом по HTTPS отвергать подключения по HTTP в течении указанного в параметре max-age времени. На время отладки эту опцию рекомендуется закомментировать.

Теперь откроем главный файл конфигурации Apache /etc/apache2/apache2.conf и добавим туда глобальные опции, отвечающие за шифрование:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off
SSLSessionTickets off
SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

Так как правильное их формирование вопрос сложный, то рекомендуем воспользоваться специальным генератором moz://a SSL Configuration Generator. В нашем случае взяты настройки среднего уровня (Intermediate) обеспечивающие необходимый баланс между безопасностью и совместимостью. Рекомендуем время от времени посещать указанный сайт и обновлять настройки шифрования собственного сервера.

Подключим необходимые модули Apache и виртуальный хост для работы с SSL:

a2enmod headers
a2enmod rewrite
a2enmod ssl
a2ensite default-ssl

Проверяем конфигурацию и перезапускаем веб-сервер:

apachectl -t
service apache2 restart

Если все сделано правильно, то при обращении к веб-публикации 1С она будет открываться только через защищенное соединение.

Включаем дополнительную аутентификацию по паролю

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

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

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

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

htpasswd -c /etc/apache2/.htpasswd user1c

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

htpasswd  /etc/apache2/.htpasswd glbuch

Затем в директории публикации базы, например, /var/www/infobase создадим файл .htaccess:

nano /var/www/infobase/.htaccess

И добавим в него следующие строки:

AuthType Basic
AuthName "Restricted Content"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user

Первая строка включает Basic-аутентификацию, вторая задает наименование области безопасности, можете вписать туда все что угодно. Затем указывается путь к файлу паролей и политика аутентификации, valid-user обозначает что доступ получит любой аутентифицированный пользователь. Если нужно указать конкретные учетные записи, то последнюю строку нужно изменить следующим образом:

Require user user1c glbuch

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

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

Если вы используете для доступа к опубликованным на веб-сервере базам тонкий клиент, то увидите дополнительное окно аутентификации на веб-сервере, настроить запоминание пароля здесь нельзя и это может быть неудобно пользователям.

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

/WSN user1c /WSP Pa$$w0rd_1

Где ключ /WSN определяет пользователя веб-сервера, а ключ /WSP - пароль.

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

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.