ГосТех: неизбежное случилось или Революция в управлении государственными системами (ч.1)

Многие уже наслышаны о такой платформе как ГосТех, но до сих пор не все понимают для чего мы этим занимаемся и каких усилий нам это стоит. В этой статье руководитель сектора внедрения и поддержки технологических решений Центра цифровой трансформации Татарстана Александр Лебедев ответит на следующие вопросы:

- как выглядел переезд сервиса «Мои субсидии» на ЕЦП «ГосТех»

- почему этот проект так важен для нас и для чего мы решили переехать на ЕЦП «ГосТех»

ГосТех: неизбежное случилось или Революция в управлении государственными системами (ч.1)

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

После непродолжительной официальной переписки мы получили добро на переезд от Минцифры России и приступили к работе с ГосТехом. Началось всё с соглашения о взаимодействии между регионом и ФКУ «ГосТех» (подведомственное учреждение Минцифры России). Дальше мы согласовали архитектуру нашего проекта и функциональные технические требования с ФКУ «ГосТех». На этом этапе отдельное спасибо ребятам из ФКУ за максимально подробное погружение команды в особенности работы платформы и ее сервисов для правильной адаптации архитектуры системы при миграции. Продолжили выпуском нашего первого заказа с указанием, какие услуги и ресурсы нам требуются. Дорабатывали мы наш заказ 9 раз, можно не пытаться предусмотреть всё с первого раза, чем больше мы вникали в платформу, тем больше инструментов хотелось освоить, их мы и дозаказывали. Вместе с матрицей коммуникаций всё это уходило государственному оператору платформы – ФКУ «ГосТех».

Переезжала в нашем случае система «Мои субсидии» - сервис поддержки для малых и средних предприятий, частных фермеров и граждан. Сервис «Мои субсидии» вошел в список проектов, отобранных для миграции на платформу «ГосТех». Проект разработан Минцифры Татарстана и переведен на платформу «ГосТех» с участием Минцифры России и ФКУ «ГосТех». Технологическим партнером выступил Сбер. (подробнее читайте также в статье https://vc.ru/services/1624056)

После знакомства с системой и платформой был выстроен поэтапный план переезда:

- подготовка самой системы для работы на технологическом стеке платформы

- развёртывание сервиса на тестовом и промышленном стендах платформы

- проведение аттестации системы в соответствии с требованиями ФСБ и ФСТЭК России

- прохождение приёмо-сдаточного испытания

- выход в промышленную эксплуатацию

Первый этап

Заключался он в оценке наших инструментов и инструментов платформы. Мы получили доступы, проверили оценку. По итогам поняли, что нам требуется интеграция центра уведомлений и СМЭВ workera на rest запрос, также переход с расширения jsquery для postgres на SQL Pangolin.

Второй этап

Нам создали namespace, ошибок по выделению ресурсов не было. Готовую сборку мы загрузили в Nexus. Отсюда наш проект подтянулся в K8s. Контейнеры могли работать, но были изолированы от внешней среды. Для доступов к разного рода внешним интеграциям требовалась аттестация проекта. Надо учесть, что доступ ко внешним интеграциям должен быть учтён в Модели угроз и нарушителя, а конечные хосты, к которым нужно подключиться, должны иметь аттестаты соответствия. По заказу нам выделили 3 виртуальные машины, которые имели сертифицированную ФСТЭК систему AltLinux SP 8. На этом же этапе мы уже начали получать технические учётные записи для работы в сервисах. Самое интересное в этом этапе было полное освоение систем мониторинга проекта. Было приятно узнать, что эта тема здесь отлично развита. Есть как стандартный вид мониторинга утилизации ресурсов и запросов через стэк Victoria Metrics и Grafana, так и мониторинг по методологии SIEM. Привилегированные пользователи попадают на промышленный стенд через СКДПУ, проходя модуль анализа поведения, есть видеозапись рабочего стола, полное логирование событий, кто, куда и как нажимает. Мониторится весь сетевой трафик.

В этом уже функционально богатом стэке мониторинга нам не хватило только трассировки запросов, над которым мы работаем на данный момент. Сложным оказался этап перехода на платформу в части подписания запросов в СМЭВ от устаревшего компонента Digs к программно-аппаратному комплексу Jinn Server. Сложность состояла в том, что мы долго ждали его развертывания на технической площадке и смогли опробовать его работу, чтобы оптимизировать нашу систему для работы с ним, только в самый последний момент.

Третий этап

Он был один из самых весёлых и интересных. Разберём его подробно. Аттестация началась с классификации нашей системы. В данном случае это было КС-3, УЗ-3. Разработка модели угроз и нарушителя не заняла много времени, поскольку ФКУ «ГосТех» заранее разработали шаблон и согласовали его с регуляторами в сфере ИБ (ФСБ России и ФСТЭК России). Далее технический паспорт системы вместе с моделью угроз ушёл на согласование в ФСБ и ФСТЭК.

Получив, с неожиданными приключениями, нужный нам пакет документов мы отправили его в ФКУ «ГосТех» с приложением корректирующей заявки на услугу проведения аттестации. После чего начался период рассмотрения всей имеющейся документации аттестационной комиссией. На этом этапе замечаний у нас не было. Мы получили ссылку безопасной загрузки наших контейнеров для анализа на уязвимости. Вот отсюда и начинается самое интересное в проекте: по итогам этой проверки было получено около 800 уязвимостей от разного рода компонентов системы, начиная от проблем в операционной системе, заканчивая самим кодом системы. Мы испугались, что исправление всего этого потребует нескольких месяцев работ и с досадой начали тщательную подготовку к устранению замечаний по итогам проверки; в течение двух дней плотно анализировали каждую из уязвимостей и какое было наше удивление и одновременно облегчение, что проблемы для нас оказались решаемы в кратчайшие сроки. Оказалось, что проект просто отстал на обновление языка java, нашего фрейморка, который мы использовали, драйвера базы данных, и других небольших обновлений библиотек. Успешно завершив этот этап, мы встали на повторную проверку проекта и уже успешно его завершили. Дальше нам предстояло пройти проверку пентестом, которая для нас прошла уже легче, потребовались небольшие обновления, с которыми мы справились быстро. В завершение этого этапа был проведен сеанс ВКС, где нас поздравили с тем, что нашу систему вписали в аттестат платформы и рассказали об ответственности при эксплуатации аттестованной системы, в том числе и уголовной. Также объяснили порядок взаимодействия платформы ГосТех с ГосСОПКА.

Получив полезные наставления, мы двинулись дальше.
Получив полезные наставления, мы двинулись дальше.

Четвёртый этап

Этап ПСИ для нас прошёл гладко, никаких проблем не возникало. Начался этот этап как раз с написания заявок в СД на выделение доступов. Тут же мы поймали себя на мысли, что паспорт региона PD40 отображал не все данные, которые нам нужны от используемой инфраструктуры, и параллельно проводили консультации с архитекторами Сбера, как нам лучше интегрироваться с сервисами платформы, как написать заявки на доступ, просьбы прислать IP-адреса, протоколы и порты для связи. Кстати, на данный момент паспорт региона стал более информативным, чем раньше.

На данном этапе после всех ключевых проверок мы начали активный перенос данных из старой инфраструктуры в новую. Здесь мы переносили базы данных пользователей keycloak, базу центра уведомлений, S3.

Пятый этап

Ввод в промышленную эксплуатацию, к сожалению для проекта, прошёл не самым гладким образом. Опишу наш опыт, чтобы было понимание с чем можно столкнуться. Сам проект переехал в новую для нас инфраструктуру, используя те же инструменты, многие из них были мажорной версией выше, также в рамках аттестации многие компоненты были обновлены. Проект перед переездом был на время проведения работ выключен; сделано это было чтобы пользовательские данные не изменились после переноса бэкапов. Накопилась очередь заявителей, размером которая ещё никогда не заходила на наш проект. Как итог, рассчитанная для нас оценка нагрузки оказалась недостаточной. Некоторые перебои в работе наблюдались и в самой платформе на старте, сейчас уже всё пофиксили. Имели место и точечные проблемы с работой проекта, связанные с недоступностью компонентов или работы ресурса. Позднее оказалось, что была проблема WAF, обучив и поставив его на боевой режим, он начал блокировки подозрительного с его точки зрения трафика. Также защита была заново переобучена, данных проблем мы больше не наблюдаем.

Ответ на вопрос «Почему ГосТех важен для нас?» читайте во второй части!

Начать дискуссию