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

В этой статье хочу разобрать кейс об организации системы удаленной работы сотрудников в банковском секторе, который мы с коллегами из «ЛАНИТ-Интеграции» внедрили в крупном российском банке.

Из чего состоит система удаленной работы сотрудников банковского сектора

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

• полную или частично удаленную работу; 

• использование различных мобильных устройств, как корпоративных, так и BYOD (Bring your own device — концепция, поощряющая использование собственного цифрового оборудования вместо официального предоставленного). Безусловно, большинство сотрудников пользуются корпоративными устройствами (некоторые компании даже выдают автомобили), но не будем исключать процент используемых личных гаджетов для работы. 

В связи с этим, перед ИТ-отделами частных и государственных компаний встает широкий спектр непростых технических задач по обеспечению: 

• возможности удаленной работы с приложениями с любых устройств; 

• удобных и максимально приближенных к офисным условиям для эффективной работы пользователей; 

• защиты корпоративных данных от многочисленных современных угроз (несанкционированного доступа, хищения, атак шифровальщиков и т.д). 

Если сузить этот спектр до организации гибридной работы с on-premises приложениями, то можно выделить следующие задачи: 

• защищенное подключение пользователей к локальной сети офиса через интернет; 

• установка на мобильные устройства пользователей системы управления этими устройствами (MDM, MAM и др.); 

• предоставление доступа к приложениям/ресурсам (файлам, папкам, программам, веб-порталам и т.д.). 

Основное внимание в этой статье уделим российскому решению WorksPad, относящемуся к классу систем управления мобильными устройствами MAM (Mobile Application Management).

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

Как мы подошли к выбору системы WorksPad

Начнем с краткого обзора компонентов по обеспечению безопасности удаленки.

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

С технической точки зрения в серверной части можно отметить следующие особенности: 

• быстрое развертывание; 

• удобное масштабирование; 

• простую процедуру обновления;

• микросервисную stateless-архитектуру, написанную на C#;

• малый размер дистрибутива (50-110 МБ в зависимости от версии).

Front-End серверы WorksPad могут работать как под управлением ОС семейства Microsoft Windows Server на веб-сервере IIS, так и под Linux (Astra Linux, Debian) на веб-серверах Apache/Nginx. Возможно совместное использование с балансировщиками нагрузки. 

Back-End серверы поддерживают как СУБД Microsoft SQL Server (Windows), так и PostgreSQL (Linux). 

Возможна интеграция с системами электронной почты: 

• Communigate Pro; 

• Microsoft Exchange; 

• RuPost; 

• Zimbra. 

С точки зрения потребления ресурсов основная нагрузка ложится на Back-End. WorksPad - по сути «посредник» между конечными пользователями и предоставляемыми им сервисами (электронной почтой, веб-порталами, общими файловыми папками, библиотеками SharePoint и т.д.). Поэтому нагрузка на базу данных в основном идёт на чтение. Основную часть нагрузки на запись представляют логи. 

Для работы WorksPad необходимо наличие в инфраструктуре предприятия службы каталогов (Microsoft Active Directory, ALD Pro, FreeIPA, OpenLDAP). Она используется для импортирования списков пользователей и дальнейшего предоставления им необходимых доступов. 

Безопасность сетевого подключения обеспечивается с помощью протокола HTTPS. Для шифрования трафика между службами WorksPad может использоваться как самоподписанный цифровой сертификат, который автоматически инсталлируется при установке серверной части, так и вариант внутреннего центра сертификации (ЦС). 

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

Клиентская часть WorksPad представляет собой защищенный контейнер, предлагающий удобное решение «всё в одном»: 

• почтовый клиент; 

• веб-браузер; 

• файловый браузер; 

• просмотр и редактирование файлов (все основные офисные форматы, Word, Excel, PDF, архивы). 

Клиент доступен через магазины приложений как для Android, так и для iOS. Есть несколько редакций: 

• WorksPad с более классическим интерфейсом и поддержкой старых версий ОС; 

• WorksPad X с более современным интерфейсом и расширенным функционалом; 

• WorksPad R/RX с шифрованием данных с помощью алгоритмов ГОСТ на основе криптографических библиотек «ИнфоТеКС» ViPNet. 

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

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

• цифровой сертификат для доступа клиентов прошёл проверку подлинности; 

• подключение принял сервер WorksPad по проприетарному протоколу. 

Это накладывает ограничения: 

• невозможность добавления в клиент учётных записей общедоступных сервисов электронной почты (Yandex, Mail.ru, Google и т. д.); 

• невозможность использования систем промежуточной аутентификации (Authentication Virtual Server в Citrix ADC и т. д.).

Безопасность аутентификации может быть усилена на стороне клиента с помощью использования локального пароля приложения. В редакции WorksPad R/RX это является обязательным. Пароль хранится непосредственно на устройстве и не передается по сети. 

Минимальная длина локального пароля – 6 символов. Она задаётся политиками WorksPad и никак не связана с политиками минимальной длины пароля в службах каталогов. 

Настройка локального пароля проходит по такому алгоритму: 

• создание закрытого ключа посредством движения пальцем по экрану мобильного устройства; 

• ввод доменного логина и пароля для первой аутентификации пользователя на устройстве; 

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

В дальнейшем при каждом входе в WorksPad нужно будет вводить только локальный пароль (сохранить его нельзя). 

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

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

В программу встроены водяные знаки, показывающие доменное имя пользователя, ID экземпляра приложения и слова «конфиденциально». Возможно добавление текстов по желанию заказчика. 

С теорией закончили, а теперь переходим к практике.

Реальный кейс: как мы усовершенствовали существующую инфраструктуру на базе WorksPad в крупном банке

Исходные данные 

Модернизация инфраструктуры WorksPad была частью проекта по внедрению системы удалённой работы у одного из наших заказчиков. Как вы уже поняли, это был крупный российский банк, у которого высокие требования безопасности. Поэтому в рамках проекта была создана отдельная система, практически полностью независимая от основной ИТ-инфраструктуры банка. Например, своё серверное и сетевое оборудование, отдельный лес Active Directory и др. По сути, эта концепция была посредником между юзерами и головной инфраструктурой банка, в которой находились пользовательские ресурсы (удаленные рабочие столы, электронная почта, система документооборота, производства и т.д.). 

Ключевая проблема 

Изначально механизм был рассчитан на довольно узкое применение. Предполагалось, что им будет пользоваться только руководящий состав банка. В техническом задании к первой очереди был указан максимум - 100 пользователей с возможностью расширения до 500 ко второй очереди. 

Инфраструктура WorksPad состояла из двух независимых серверов: основного и тестового. Их настройки не были идентичными. Роли Front-End и Back-End были совмещены на обоих. Серверы были опубликованы через Microsoft Forefront TMG 2010, балансировка нагрузки отсутствовала. 

Вследствие массового перевода сотрудников банка на удаленную работу из-за пандемии, количество пользователей WorksPad резко выросло до тысяч, в несколько раз превзойдя заранее заложенные возможности расширения. Сложностей добавляло то, что работники были распределены по всей территории России, то есть система должна была быть доступна круглосуточно. Резко возросла нагрузка не только на WorksPad, но и на все остальные сервисы (как аппаратные, так и программные компоненты), ухудшилось качество обслуживания, участились прерывания в работе сервисов. А вскоре перед ИТ-отделом заказчика была поставлена задача обеспечить возможность одновременной работы почти 10 тысяч сотрудников. 

Решение 

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

Состав новой инфраструктуры был следующим: 

• 2 Front-End на Windows Server 2019; 

• 2 Back-End в отказоустойчивом кластере БД SQL Always On на SQL Server 2019; 

• балансировка нагрузки с помощью Citrix ADC. 

Все серверы были виртуальными с таким выделением ресурсов: 

Итоговая схема работы WorksPad выглядит следующим образом: 

Здесь нужно отметить, что для работы push-уведомлений для пользователей о сообщениях электронной почты используется облачная часть сервиса WorksPad, взаимодействующая с облаками Apple/Google. 

Процедура миграции состояла из следующих шагов: 

• настройка Front-End: 

  • настройка брандмауэра; 

  • создание служебных учётных записей WorksPad; 

  • настройка взаимодействия с Microsoft Exchange; 

• настройка Back-End: 

  • настройка брандмауэра; 

  • настройка Windows Failover Cluster; 

  • настройка SQL Availability Group. 

• перенос БД; 

• установка серверной части WorksPad на Front-End; 

• перенос локальных настроек Front-End; 

• настройка Citrix ADC на публикацию и балансировку Front-End; 

• изменение DNS-записи, к которой обращаются пользователи. 

Давайте рассмотрим эти пункты более подробно. 

Регулировка Front-End включала в себя стандартную процедуру установки и настройки ОС Windows Server, развёртывание роли IIS и установку Microsoft ASP.NET Core 6.0. 

Полный список используемых в настройке брандмауэра сетевых портов приведен в руководстве по установке и настройке. В основном используется взаимодействие во внутренней сети по протоколу HTTPS (TCP порт 443). Для защищенного веб-браузера в классической версии приложения требуется доступ по TCP-порту 5757. Также сервер WorksPad должен иметь доступ по HTTPS к расположенным в Интернете серверам push-уведомлений и серверам активации лицензий (их адреса указаны в документации). 

Основная системная учетная запись (УЗ) требует следующих прав: 

• членство в группе локальных администраторов на серверах Front-End; 

• вход в качестве администратора и пакетного задания на серверах Front-End; 

• владельца БД WorksPad на Back-End. 

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

Для настройки взаимодействия с применяемым у заказчика Microsoft Exchange требуется системная УЗ для push-уведомлений. Она позволяет создавать от имени пользователя подписки на получение почтовых уведомлений от Exchange, а также получать необходимую для отправки push-уведомлений информацию. 

Дальнейшие шаги по настройке взаимодействия с Exchange включают в себя: 

• развертывание клиентских библиотек Microsoft Exchange Web Services Managed API; 

• настройку доступности службы Exchange Autodiscover с Front-End; 

• настройку новой Throttling Policy в Microsoft Exchange; 

• привязку Throttling Policy к почтовым ящикам пользователей WorksPad; 

• привязку Throttling Policy к системной УЗ для push-уведомлений; 

• добавление роли ApplicationImpersonation системной УЗ для push-уведомлений. 

Настройка новой Throttling Policy требуется в связи с довольно низкими порогами этих политик по умолчанию для Exchange Web Services. Высока вероятность временных отказов в обслуживании запросов (или более медленное их обслуживание) со стороны Exchange Server для ящиков больших размеров, особенно при первоначальной синхронизации. 

В нашем случае процесс миграции облегчался тем, что данные УЗ уже были настроены для старой инфраструктуры. 

Настройка Back-End включает в себя стандартную процедуру установки и настройки ОС Windows Server, SQL Server и Microsoft ASP.NET Core 6.0. Отметим, что поддерживается любая редакция SQL Server, включая Express. Однако, следует учитывать её ограничения (максимум 1 ГБ RAM и максимум 10 ГБ для БД). 

Настройка Windows Failover Cluster и SQL Availability Group не имеет каких-то специфических особенностей. 

Перед миграцией БД необходимо остановить на старом сервере все службы WorksPad и IIS. Далее используется стандартный для MS SQL Server алгоритм: 

• сделать полную резервную копию БД; 

• восстановить БД из резервной копии на обоих нодах кластера; 

• добавить БД в SQL Availability Group. 

Только после этого можно начинать установку серверной части WorksPad на серверы Front-End. Процедура не представляет особой сложности, это типичный Next – Next – Finish и подробно описана в документации. Здесь стоит отметить, что на шаге ввода параметров базы данных в имени сервера БД необходимо указать имя ранее настроенного SQL Availability Group Listener. 

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

• использования алгоритма RSA;

• наличия закрытого ключа с типом AT_KEYEXCHANGE; 

• Key Usage = Key Encipherment; 

• Enhanced Key Usage = Server Authentication. 

В случае выбора RSA, после установки на первом сервере, необходимо выгрузить самоподписанный сертификат вместе с закрытым ключом и установить его на второй сервер. Это можно сделать как с помощью стандартных средств Windows, так и с помощью DLL библиотеки WorksPad через командную строку (процедура подробно описана в документации). 

Во втором варианте можно запросить для сервера сертификат по встроенному в Windows Server Certification Authority шаблону Web Server. В поле Subject рекомендуется указать тип Common Name, в нем FQDN (Fully Qualified Domain Name) сервера, в поле Subject Alternative Name тип DNS, в нем FQDN и CN сервера. Далее необходимо выгрузить стандартными средствами Windows полученный сертификат вместе с закрытым ключом и установить его на второй сервер. 

После выполнения этих процедур можно ставить компоненты на второй сервер по аналогии с первым. 

Несмотря на то, что большая часть настроек системы находится в БД, некоторые параметры Front-End находятся в текстовых файлах JSON (подробное описание в руководстве по установке, глава 10 «Конфигурирование системы»). В нашем случае это относится к службам Gateway, Archiver и настройкам прокси-сервера. Если конфигурации служб по умолчанию были изменены на старом сервере, их нужно скопировать в соответствующие файлы на новых серверах и перезапустить службу IIS.  

После этого можно приступать к налаживанию балансировщика нагрузки. Рассказ о полной настройке данного функционала выходит за рамки нашей статьи. Здесь нужно отметить следующие важные моменты.

• Балансировать необходимо трафик HTTPS/WSS по порту 443 и TCP-трафик по порту 5757.

• Балансировщик должен уметь работать в режиме сохранения сессии (session persistence), например, на основе IP-адреса источника. 

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

Как правило, при миграции требуется на какое-то время оставить в работе старую инфраструктуру. Поэтому следует продумать изменения в DNS-записях, по которым обращаются пользователи. Мы задействовали вариант, в наименьшей мере затрагивающий их: имя старой записи осталось без изменений, прописали для него IP-адрес нового кластера. Для старой инфраструктуры была заведена новая запись со старым IP-адресом. 

Обслуживание WorksPad

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

Одним из основных инструментов диагностики любой ИТ-системы является изучение ее логов. Они хранятся в базе данных WorksPad и их можно смотреть двумя способами: через веб-интерфейс системы или напрямую через запросы к таблицам БД (например, с помощью SQL Management Studio). Второй вариант может помочь при необходимости взаимодействия с системами сбора логов (например, SIEM), так как на текущий момент встроенных средств интеграции с ними у WorksPad нет. При этом нужно учитывать, что названия событий в веб-интерфейсе и таблицах могут отличаться.  

Логи можно архивировать, по умолчанию они будут перемещаться в отдельные таблицы основной БД WorksPad, но есть и вариант настройки архивации в отдельную базу. Также можно настроить «возраст» событий, по достижении которого они будут перемещаться в архив (30 дней по умолчанию), и максимальное количество событий в одном архиве (то есть в одной таблице БД 500 тысяч по умолчанию). 

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

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

Специфических требований к продуктам резервного копирования и их работе у WorksPad нет. Можно делать бэкапы виртуальных машин Front-End и Back-End полностью, но при этом бэкапы БД обязательно нужно делать отдельно. 

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

1. создать резервную копию БД WorksPad; 

2. на балансировщике нагрузки перевести любую ноду WorksPad в режим обслуживания; 

3. запустить на активной ноде обновление от служебной учетной записи; 

4. проверить работоспособность клиентов; 

5. если клиенты работают, обновить ноду, которая находится в режиме обслуживания, по аналогии с третьим пунктом; 

6. включить на балансировщике ноду, находящуюся в режиме обслуживания, в активный режим. 

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

Если же требуется провести откат обновления (например, возникли проблемы в работе клиентов), то оно выполняется по алгоритму: 

1. на балансировщике перевести обновленную ноду в режим обслуживания; 

2. остановить службу IIS на обоих серверах; 

3. восстановить БД из резервной копии; 

4. на балансировщике перевести в активный режим необновленную ноду; 

5. проверить работоспособность клиентов; 

6. удалить WorksPad на обновлённой ноде (установка старой версии поверх новой не поддерживается); 

7. установить предыдущую версию WorksPad на обновлённой ноде; 

8. на балансировщике перевести в активный режим обновленную ноду в балансировку. 

Вывод

К преимуществам WorksPad можно отнести: 

• простоту установки и обновления; 

• прозрачность процесса миграции;

• масштабируемость (поддержка работы более 10 тысяч пользователей); 

• поддержку широкого спектра российских и зарубежных программных продуктов; 

• удобство для пользователей и администраторов; 

• высокий уровень защиты корпоративных данных; 

• большое количество настроек защиты данных. 

Но нашлись и недостатки: 

• для системных учётных записей нельзя использовать gMSA/MSA; 

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

• отслеживание действий пользователя возможно лишь частично; 

• нет встроенной интеграции с SIEM-системами; 

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

Удаленная работа стала неотъемлемой частью жизни сотрудников многих компаний и грамотный процесс перехода – мастхэв для крупных организаций. Имея опыт внедрения различных ИТ-систем в «ЛАНИТ-Интеграции» и после завершения кейса с банковской сферой могу сказать, что российский WorksPad успешно решает задачи, связанные с обеспечением гибридной работы с on-premises приложениями и может быть рекомендован, если вам нужно заменить прежнюю систему на отечественную. Желаю удачи!