Перейти к содержанию

Настройка production сервера

Рекомендации в данном разделе описывают настройки TESSA, которые рекомендуется выполнить для production установки для повышения безопасности и противодействия атакам. Описанные настройки связаны с веб-сервисом в целом и не относятся к бизнес-требованиям, правилам доступа и др.

Крайне рекомендуется выполнить такую настройку, если с системой возможна работа вне защищённого контура.

Tip

Перечисленные настройки актуальны как для Windows, так и для Linux инсталляций.

Настройки в файле app.json веб-сервиса

Warning

При установке в кластере серверов приложений перечисленные настройки необходимо выполнить в файле app.json на каждом из серверов.

Note

Перечисленные настройки актуальны для TESSA 3.6.0.2 или старше. Для более ранних версий могут отсутствовать некоторые из перечисленных параметров, но большинство из них применимо. Аналогично, большая часть настроек применима для TESSA 3.5.0.12 или старше. Для повышения безопасности мы рекомендуем обновить систему до последней доступной версии или минимум до LTS версии.

В папке “web” веб-сервиса TESSA содержится файл app.json, в котором рекомендуется установить следующие значения параметров.

  1. Параметр: 
    "Configuration.Sealed": true

Параметр true предотвращает любые изменения конфигурации, выполняемые даже от административных учётных записей. Это включает в себя изменения рабочих мест, представлений, схемы данных, типов карточек/файлов/диалогов/заданий, любые изменения в карточках настроек, а также редактирование любых скриптов C# и SQL (см. ниже в разделе по параметру Configuration.StrictSecurity).

Установите true, если с системой работают пользователи. Значение false устанавливайте только на время обновления конфигурации, которое рекомендуется выполнять автоматизированными средствами с использованием утилиты tadmin. После завершения обновления установите значение true.

После изменения значения параметра требуется перезапустить сервер приложений (пул приложений или Linux сервис).

При наличии защищённого контура рекомендуем установить в нём выделенный веб-сервер, доступный только внутри контура (без доступа в Интернет) для компьютера, с которого будет запускаться обновление (скрипт с использованием tadmin, такой как Upgrade.bat/upgrade.sh). Доступ других компьютеров к этому серверу необходимо ограничить, насколько это возможно в вашей сетевой конфигурации. Для этого веб-сервера параметр Configuration.Sealed устанавливается как false и не изменяется. После выполнения обновления через tadmin кластер серверов приложений, расположенный вне контура, рекомендуется перезапустить, или же выделенный сервер должен быть подключён к Redis вместе со всеми серверами в кластере.

  1. Параметр: 
    "Configuration.StrictSecurity": true

Параметр true определяет режим, в котором даже от административных учётных записей недоступно:

  • Редактирование любых скриптов C# и SQL, в т.ч. содержащихся в маршрутах, бизнес-процессах, динамических и контекстных ролях, генераторах метаролей, в типах условий, в шаблонах файлов, в виртуальных файлах и в уведомлениях.
  • Просмотр структуры карточек в web-клиенте и в TessaClient от любых учётных записей.
  • Импорт карточек из приложения TessaClient. При этом сохраняется возможность импорта из приложений TessaAdmin и tadmin (если импортируемые карточки не содержат скрипты).
  • Назначение пользователям уровня доступа “Администратор”.

Установите true для production-сервера, когда с системой работают пользователи. Значение false устанавливайте только на время обновления конфигурации, которое рекомендуется выполнять автоматизированными средствами с использованием утилиты tadmin. После завершения обновления установите значение true.

При наличии защищённого контура актуальны те же рекомендации, что и для параметра "Configuration.Sealed".

  1. Параметр: 
    "HealthCheckIsEnabled": false

Установите false, чтобы сделать недоступным веб-страницу по адресу /check (например, https://tessa-server.org/tessa/web/check), в которой содержится диагностическая информация и выполняются проверки по работоспособности различных компонентов системы. Страница не требует аутентификации, что может использоваться для исполнения DoS атак.

При разворачивании системы в среде контейнеризации Docker используйте адрес /hcheck для проверки работоспособности веб-сервиса TESSA в контейнере. Адрес /hcheck остаётся доступным, независимо от значения этого параметра.

  1. Параметр: 
    "SwaggerDocIsEnabled": false

Установите false, чтобы сделать недоступными страницы с описанием Swagger (документация OpenAPI по REST методам веб-сервиса, используемая при интеграции). Страницы обычно доступны по адресу /swagger (например, https://tessa-server.org/tessa/web/swagger), в которых содержится подробная информация по взаимодействию с веб-сервисом, которая может использоваться злоумышленником совместно с другими видами атак.

  1. Параметр: 
    "CookiesSameSite": "Strict"

Параметр "Strict" предотвращает передачу cookies web-клиента TESSA при выполнении CSRF-атак с веб-страниц других сайтов, не принадлежащих домену, на котором размещён сервер TESSA. Другие доступные значения перечислены в разделе Настройка конфигурационного файла.

  1. Параметр: 
    "TokenCookiesName": "token"

Имя cookies для хранения токена сессии TESSA. В том случае, когда иное приложение на стороне пользователя использует cookies с тем же именем, его можно переопределить.

Если параметр не задан в файле конфигурации, то используется значение по умолчанию: token.

  1. Параметр: 
    "CheckPlatformVersion": true

Параметр true запрещает подключение приложений desktop-приложений TessaClient и TessaAdmin с запросом метаинформации по системе, если приложения были собраны для более ранней версии платформы TESSA. Настройка не влияет на приложения TessaAppManager и tadmin, а также на web-клиент (который не пройдёт такую инициализацию для релизных версий платформы TESSA, независимо от настройки).

Настройка не влияет на возможность запуска приложений с другим номером патча, поскольку версия платформы определяется строкой вида “3.6 от 06.06.2021” и для патчей она не изменяется. Строка с версией отображается в “О программе” для TessaClient и web-клиента, на вкладке “Информация” для TessaAdmin и на веб-странице по адресу /check.

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

  1. Параметр: 
    "SessionExpirationTimeSpan": "7.00:00:00"

Максимальный срок жизни сессии, по умолчанию указан как 7 дней. Актуален и для desktop-приложений, и для web-клиента, и для любых интеграционных взаимодействий.

Desktop-приложения автоматически пересоздают сессию, если срок её завершения близок, для этого не требуется отдельных настроек. Приложение web-клиента при отсутствии сессии выполняет redirect на страницу логина с указанием обратной ссылки, которую браузер откроет сразу после успешного входа, при этом от пользователя потребуется ввести логин/пароль или выполнить Windows-аутентификацию.

Пока сессия не истекла, пользователь web-клиента сможет не выполнять логин и открывать ссылки системы сразу же в течение указанного периода времени.

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

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

Если вы измените значение более, чем на значение по умолчанию, то также измените настройку Maintenance.RemoveInactiveSessionsOlderThanDays в файле app.json для сервиса фоновых процессов Chronos. Увеличение срока жизни сессии снижает безопасность.

  1. Параметр: 
    "CipherKeyRotationInterval": "10.00:00:00"

Срок ротации ключей шифрования для содержимого файлов, скачиваемых и кэшируемых на компьютере пользователя посредством Deski (приложением-помощником web-клиента). Deski сможет расшифровать файлы, зашифрованные текущим или предыдущим ключом пользователя, т.е. срок доступа к файлам равен двум интервалам ротации, по умолчанию это 20 дней. Файлы в кэше, которые не расшифровываются текущим или предыдущим ключом, удаляются, и их содержимое заново запрашивается с сервера.

Настройка по умолчанию предоставляет достаточную безопасность. Проконсультируйтесь с вендором при необходимости её изменить.

  1. Параметр: 
    "ViewAccessCacheTimeSpan": "0.01:00:00"

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

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

  1. Параметр: 
    "AllowedRefererValues": [ ]

Если планируется использовать web-клиент TESSA, то перечислите здесь доменные имена (с опциональным указанием путей), которые должны содержаться в заголовке Referer (заголовок отправляется браузером с каждым запросом).

Например: 

"AllowedRefererValues": [ "https://tessa-server.org/tessa/web", "https://other-tessa.com" ]

Сервер вернёт ответ 403 Forbidden на любой запрос, заголовок Referer которого не удовлетворяет одному из указанных значений, т.е. текст заголовка не начинается с одной из перечисленных строк (при проверке к строкам неявно добавляется символ /, чтобы предотвратить частичное совпадение). Это улучшает противодействие CSRF-атакам.

  1. Параметр: 
    "ResponseHeaders": {
     "X-Frame-Options": "sameorigin",
     "X-XSS-Protection": "1; mode=block"
 }

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

Рекомендуется сохранить значения по умолчанию:

  • X-Frame-Options - значение "sameorigin" предотвращает встраивание страницы web-клиента в html-тег <iframe>, если страница с тегом расположена на другом домене или использует другую схему аутентификации. Измените это значение только в том случае, если требуется такое встраивание, это снизит противодействие CSRF-атакам.

  • X-XSS-Protection - значение "1; mode=block" предотвращает выполнение опасных скриптов, которые оказались встроены как внешнее html-содержимое в страницу web-клиента - это повышает противодействие XSS-атакам. Веб-приложение TESSA использует другие средства для обработки содержимого веб-страницы перед её отображением, чтобы XSS-атаки были невозможны. Использование этого HTTP-заголовка дополнительно включает защиту от браузера, что повышает защищённость, даже если в проектном решении используются компоненты, подверженные уязвимости (например, элементы управления или формы).

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

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

  1. Изменение настроек файловых хранилищ для индивидуальных серверов

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

Обратитесь к разделу Изменение настроек файловых хранилищ через конфигурационный файл, где описаны такие настройки.

  1. Параметр: 
    "WebControllers": [ "extensions/Tessa.Extensions.Default.Server.Web.dll", "extensions/Tessa.Extensions.Server.Web.dll" ]

Если в проектном решении не разрабатывались дополнительные контроллеры web-приложения, размещённые в проекте расширений Tessa.Extensions.Server.Web, то отключите этот контроллер посредством указанного параметра. Проект контроллера по умолчанию содержит примеры написания собственных контроллеров, доступные по пути /service, которые уязвимы для различных видов атак.

Замените параметр на: 

"WebControllers": [ "extensions/Tessa.Extensions.Default.Server.Web.dll" ]

Если же в проектном решении разрабатывались контроллеры для интеграций или кастомных веб-приложений, то не изменяйте параметр, но удалите файл в исходных кодах проектного решения по пути Source/Tessa.Extensions.Server.Web/ServiceController.cs.

  1. Параметр: 
    "SecureServerStackTrace": false

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

Настройки сервера на вкладке “Безопасность”

В карточке Настройки сервера на вкладке “Безопасность” присутствует ряд параметров, которые рекомендуется проверить для production-инсталляций. После изменения любых параметров на этой вкладке необходимо вручную перезапустить все серверы приложений с веб-сервисами системы.

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

  1. Неудачных попыток входа до блокировки пользователя

Укажите значение минимум 10, чтобы противодействовать подбору пароля.

Актуально для пользователей с типом входа TESSA или при ручном вводе логина/пароля для учётных записей Windows/LDAP без автоматической аутентификации Kerberos/NTLM.

  1. Неудачных попыток входа подряд (в серии) до временной блокировки

Укажите значение минимум 5, чтобы противодействовать подбору пароля.

Серия попыток определяется, в зависимости от настройки “Время между попытками входа, чтобы считать их в одной серии попыток”.

Актуально для пользователей с типом входа TESSA или при ручном вводе логина/пароля для учётных записей Windows/LDAP без автоматической аутентификации Kerberos/NTLM.

  1. Время между попытками входа, чтобы считать их в одной серии попыток

Укажите значение минимум 00:03:00, чтобы противодействовать подбору пароля.

Настройка определяет время между двумя соседними попытками в серии, не между всеми попытками в серии, т.е. серия из 5 попыток может выполняться максимум за 15 минут, где между соседними попытками максимум 3 минуты. Если это условие нарушается, то считается, что неудачные попытки ввода пароля были не в серии, в этом случае проверяется параметр “Неудачных попыток входа до блокировки пользователя”.

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

Укажите минимум 0.25, чтобы противодействовать подбору пароля. Это соответствует 15 минутам блокировки после серии неудачных попыток ввода пароля.

Если превышено количество попыток в параметре “Неудачных попыток входа до блокировки пользователя”, то пользователь будет заблокирован бессрочно, независимо от этой настройки. Разблокировать пользователя сможет администратор системы в карточке сотрудника.

  1. Выполнять блокировку сотрудников с типом входа Windows или LDAP

Установите флажок для повышения безопасности. Блокировка выполняется только для сотрудников в системе TESSA, но не учётные записи операционной системы.

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

Независимо от этой настройки для пользователей продолжат действовать настройки по блокировке учётных записей в Active Directory, в этом случае блокируется учётная запись Windows.

  1. Время неактивности, по истечении которого сессия закрывается, часы

Укажите минимум 24 часа. Активностью считаются любой запрос от клиентского приложения к веб-сервису для web-клиента или для desktop-клиентов. Возможно установить значение меньше, если это не противоречит требованиям бизнеса.

  1. Минимально разрешённая длина пароля

Укажите минимум 10, чтобы противодействовать подбору пароля.

Актуально только для пользователей с типом входа TESSA. Парольная политика для пользователей Windows/LDAP определяется в Active Directory или в каталогах LDAP.

  1. Специальные символы, цифры и разные регистры символов

Установите флажок, чтобы противодействовать подбору пароля. В этом случае в каждом пароле, задаваемом администратором или пользователем при смене пароля, должна быть минимум одна строчная буква, одна прописная буква, одна цифра и один специальный символ (знак препинания, символ доллара, процента и пр.).

Актуально только для пользователей с типом входа TESSA.

  1. Количество неповторяющихся паролей

Укажите минимум 3. Определяет, что пользователь не может изменить пароль, который равен предыдущему паролю или паролю перед ним.

Актуально только для пользователей с типом входа TESSA.

  1. Срок действия пароля, дни (пусто, если бессрочно)

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

Актуально только для пользователей с типом входа TESSA.

  1. Срок начала отправки уведомлений перед истечением срока пароля, дни

Укажите удобное для пользователей значение. Рекомендуем 5 дней. Если пользователь не сменил пароль, то в следующие дни ему также придёт почтовое уведомление с напоминанием.

Актуально только для пользователей с типом входа TESSA.

Дополнительные настройки app-web.json веб-сервиса для локальной установки без использования IIS

Если решено использовать веб-сервис TESSA в качестве front-сервера (без использования IIS, Nginx, Apache), то это возможно для небольших production-инсталляций (мы рекомендуем до 50 сотрудников).

В этом случае в файле app-web.json в папке “web” веб-сервиса TESSA указать следующие параметры в группе настроек "WebServer". Параметры в этой группе, не перечисленные ниже, влияют на поиск используемых сертификатов HTTPS и на механизм “Data Protection” веб-сервера Kestrel (его настройка по умолчанию подойдёт для production-инсталляций, кроме развёртывания в среде контейнеризации Docker). Прочитать про эти параметры можно в разделе Настройка конфигурационного файла.

  1. Параметр: 
    "HttpsRedirect": "HSTS"

Замените значение по умолчанию Enabled на HSTS, чтобы использовать опцию HTTP Strict Transport Security при перенаправлении запросов к web-клиенту TESSA с протокола http:// на протокол https://. Это позволяет браузеру после первого обращения к сайту запомнить, что в дальнейшем запросы сразу должны выполняться по протоколу https://, даже если пользователь указал ссылку http://.

  1. Параметр: 
    "HttpsRedirectPort": null

Номер порта для протокола https, на который выполняется перенаправление. Значение null соответствует стандартному порту 443. Рекомендуем его не изменять.

  1. Параметр: 
    "HstsMaxAgeDays": 365

Количество дней, на которые при использовании HSTS (см. выше) браузер запоминает, что к сайту необходимо обращаться по протоколу https:// вместо протокола http://. Более высокое значение является более безопасным, но устанавливать его сверх указанного не имеет смысла. Рекомендуем не изменять этот параметр.

  1. Параметр: 
    "Http2Disabled": false

Если указано true, то отключает использование протокола HTTP/2. Это не влияет на безопасность, но может негативно повлиять на скорость загрузки web-клиента у пользователей, поэтому рекомендуем оставить значение false кроме случаев, когда это вызывает проблемы у пользователей.

  1. Параметр: 
    "EnforceTls12": true

Укажите true, чтобы использовать только защищённый протокол TLS 1.2 (или TLS 1.3, если он поддерживается и браузером, и ОС сервера приложений). Протоколы TLS 1.0 и TLS 1.1 отключаются.

Проверьте, что у пользователей с ОС Windows 7 установлены обновления, включающие поддержку протокола TLS 1.2. Это актуально при использовании и web-клиента, и desktop-клиентов TESSA.

  1. Настройки в группе "WebServerLimits" определяют ограничения в части сетевого взаимодействия с клиентами

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

Описание каждого параметра в группе приведено в разделе Настройка ограничений и таймаутов в группе WebServerLimits.

Другие доработки и настройки

  1. Настройте регулярное обновление ключей SignatureKey и CipherKey для файлов app.json веб-сервисов “web” и фоновых сервисов Chronos

Ключи должны быть идентичны в файлах app.json на каждом из серверов приложений (в т.ч. на всех нодах кластеров).

Это закрытые ключи, которые используются для подписи служебных данных и для шифрования специфичных для пользователя данных в базе данных. Их обновление предотвращает уязвимости, связанные с перехватом предыдущих ключей, причём они не передаются по сети, но при прямом доступе к диску или к памяти серверов приложений злоумышленник может выполнять такие действия, как открытие сессий от имени любого пользователя, расшифровка файлов и др. Также предотвращается долгосрочное использование токенов сессий для пользователей (cookies) и ключей шифрования шифрованием файлов, индивидуальных для пользователей, поскольку такие ключи и токены являются производными по отношению к закрытым ключам в app.json.

Для генерации ключей используйте консольное приложение tadmin. Когда оно запущено без аргументов, отображается список доступных команд, и вы можете ввести имя команды с аргументом --help для краткой справки по этой команде, например: tadmin GetKey --help.

Для замены ключей используйте команды GetKey и SetKey с аргументами Signature и Cipher. Подробное описание команд доступно по ссылке выше.

Пример скрипта Windows batch, который генерирует ключи и затем заменяет их в папках веб-сервиса и Chronos:

@echo off
setlocal EnableExtensions
setlocal EnableDelayedExpansion



for /f "tokens=* usebackq" %%f in (`tadmin GetKey Signature`) do set Signature=%%f
for /f "tokens=* usebackq" %%f in (`tadmin GetKey Cipher`) do set Cipher=%%f



for %%a in ("C:\inetpub\wwwroot\tessa", "C:\Tessa\Chronos") do (
    tadmin SetKey Signature "/path:%%~a" "/value:%Signature%" /nologo
    tadmin SetKey Cipher "/path:%%~a" "/value:%Cipher%" /nologo
)



endlocal

Создайте Scheduled task, который запускается каждые 30 дней в нерабочее время, выполняет указанный командный файл, и перезапускает веб-сервисы и сервисы Chronos на всех серверах приложений.

Аналогично для Linux создайте shell скрипт:

#!/bin/bash



Signature=$(tadmin GetKey Signature)
Cipher=$(tadmin GetKey Cipher)



for folder in "~/tessa/web" "~/tessa/chronos"
do
    ./tadmin SetKey Signature "-path:$folder" "-value:$Signature" -nologo
    ./tadmin SetKey Cipher "-path:$folder" "-value:$Cipher" -nologo
done

Для создания периодической задачи, запускающей этот скрипт, используйте crond или cron, в зависимости от вашего дистрибутива Linux. После выполнения скрипта также требуется перезапустить веб-сервисы и сервисы Chronos.

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

  1. Установите и настройте Redis

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

Обратитесь к разделу Настройка Redis.

  1. Настройте NLog.config на порционную выгрузку логов

По умолчанию файлы логов веб-сервиса “web” и сервиса Chronos записываются в единственный файл log.txt (отдельный для каждого сервиса), который может бесконечно увеличиваться в размерах.

Для удобства просмотра и резервного копирования рекомендуется настроить конфигурационные файлы NLog.config в папке веб-сервиса “web” и сервиса Chronos таким образом, чтобы логи записывались в отдельную подпапку, где лог для каждого дня сохраняется в файл с отдельным именем. Внутри папки также рекомендуем сделать разбивку на подпапки по месяцам.

Описание настроек конфигурационного файла доступно в официальной документации NLog

  1. Настройте периодическое перестроение индексов в базе данных TESSA

Для достижения оптимальной производительности в части запросов к базе данных рекомендуется перестраивать индексы каждые 30 дней в нерабочее время.

Скрипт для перестроения индексов доступен в архиве со сборкой платформы в файле Fixes/RebuildIndexes.ms.sql для MSSQL, и в файле Fixes/RebuildIndexes.pg.sql для PostgreSQL. Для MSSQL периодическую задачу можно оформить как job в консоли СУБД, для PostgreSQL - настроить выполнение запроса, используя Scheduled task для Windows или утилиты crond/cron для Linux.

Back to top