В статье с обсуждением… инициативы по организации единой цифровой базы с информацией о населении (или вот ещё одна статья, обзорная, а вот — уже сообщение об одобрении инициативы), что, в первую очередь на порядки снижает издержки атакующего, в качестве контраргумента (альтернативы) приводилось указание на существующую систему СМЭВ (Единая система межведомственного электронного взаимодействия).

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

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

С учётом опыта товарищей с Ямала (которые на основании результатов анализа документации отдали предпочтение платформе самой распространённой ОС) и по причине отсутствия в публичном сегменте интернетов сколько-нибудь целостного описания процесса установки на платформе GNU/Linux попробую восполнить пробел.

Ибо обещания [некоторых жёлтых изданий] за денежку дать текст без каких-либо гарантий наличия в оном надлежащего ответа (есть в моём опыте примеры феерической ахинеи от профессионалов «поддержки» продаванов тырпрайс-оборудования и сертифицированных решений) — суть инфомусор.

Ранее я приводил описание заочного теоретического анализа, здесь же конспект практической части. Добавлю только, что не-знание факта распространённости блокировки пользователями JavaScript (вкупе с причинами данной практики) и, как следствие, отсутствие проверки доступности оного на ресурсе, самое отображение которого обеспечивается средствами данной технологии замечательно характеризует как разработчиков, так и заказчиков.

Как уже упоминалось, кросс-платформенность обеспечивается (хотя с учётом… особенностей реализации я склонен скорее применить термин «имитируется») использованием среды языка программирования высокого уровня Java (далее — жаба).

О проблемах с решением задачи интеграции которой с базовыми системными сервисами фрюниксов (которые наблюдаются далеко не только на примере рассматриваемого адаптера СМЭВ) разработчики явно не слышали. Не говоря о понимании и надлежащем практическом применении Знания.

Сам «адаптер» распространяется бесплатно.

Но у него есть одна проприетарная зависимость. Для работы криптографии необходимо приобрести один из двух комплектов ПО:

• КриптоПро CSP + Trusted Java 2.0 (две лицензии);
• КриптоПро JCP 2.0 (одна лицензия).

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

При этом необходимо помнить, что Сокровенное Знание о традиционном для Unix™ подходе к разработке и эксплуатации условно-работоспособного ПО давно перешло в область Священного Предания, о самом существовании которого осведомлены не только лишь все.

Лишние (и при этом совершенно ненужные) шаманства ненужны. Поэтому останавливаюсь на втором сценарии.

Немного послезнания на предмет выбора версии КриптоПро.

На момент написания статьи для загрузки доступны три версии:

• КриптоПро JCP и JTLS R2 (2.0.40035);
• КриптоПро JCP и JTLS R3 (2.0.40502);
• КриптоПро JCP и JTLS (2.0.41473).

При попытке использования версии jcp-2.0.40035 в журнале [адаптера СМЭВ] ошибка:

2020-06-23 17:27:42.040 ERROR 13579 - [main] ru.rtlabs.smev3.adapter.integration.smev.CryptoInitializer : CryptoInitializer init failure: provider with name "JCP2" not found

Откуда, кстати, следует ответ на вопрос о фиксации странных версий внешних зависимостей («commons-logging-1.1.jar и xmlsec-1.4.5.jar») в руководстве администратора.

Скачивание упоминаемой версии («На этот раз использовал JCP версии 2.0.40424.»), что интересно, недоступно.

Самую свежую версию (jcp-2.0.41473) не пробовал. Использую jcp-2.0.40502.

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

Вопрос способа удовлетворения зависимостей закономерным образом покрыт завесой молчания (из принципа «никакой угрожаемой независимой перепроверкой конкретики»). Единственное, НЯП из руководства администратора адаптера: адаптер должен использовать ту же версию Java, что и КриптоПро. При этом в дополнительных материалах (видео!!!☹) прямо указывается на использование оригинальной Java от [ныне] северо-американской корпорации Oracle.

И тут я полагаю необходимым напомнить о вывешенном в 2014 году ружже (см. Компания Oracle):

По факту: из огня, да в полымя. Из объятий одной демократической корпорации (Майкросовт), да к другой (Oracle). Хотя, если посмотреть на опыт товарищей с Ямала, нежные объятия Майкросовта не освобождают их от обязательств перед Ораклом.

Сюда же следует отметить изменение лицензионного «соглашения» (на оригинальную жабу) в апреле 2019 года (см. FAQ англ., если кто не поленится исследовать тему и перевести — буду благодарен).

Но это ещё даже не половина истории. Остаётся вопрос выбора версии. Судя по странице загрузки КриптоПро при переходе от восьмой версии Java к десятой поломали совместимость (ждём повторения истории с dev-lang/python:2).

Но тут я просто смотрю на свободную реплику (dev-java/icedtea), вижу (по состоянию на момент написания статьи) наличие только восьмой версии и делаю очевидный вывод в пользу восьмой версии. Хотя разработчик предлагает уже одиннадцатую…

Следующая развилка: выбор дистрибутива. И хотя в документации указывается на использование JRE (Java Runtime Environment), мой опыт указывает на то, что тут можно встретиться с особенностями разработки/тестирования и надёжнее сразу брать JDK (Java Development Kit. Includes a complete JRE plus tools for developing, debugging, and monitoring Java applications.). На основании наличного опыта делаю выбор в пользу последнего, без дополнительных проверок.

Лирическое отступление о принципах компоновки дистрибутива GNU/Linux

При творческом и основанном на живой практике толковании FHS (Filesystem Hierarchy Standard) необходимо отметить важный практический вывод: произвольное создание/удаление файлов возможно только (!) в домашнем каталоге пользователя (/home/…) и, с некоторыми оговорками, в /var/… и /tmp/… (для root'а — ещё и в /etc/…). Все прочие файлы должны контролироваться строго приказчиком пакетов. Предупреждение о следствиях нарушения данного принципа сформулировано ещё в 2008 году (см. #14443).

Переходим к Практике

На этом теоретическое отступление можно считать законченным и переходить к Практике. В силу некоторых обостоятельств я вынужден ориентироваться на платформу Enterprise Linux 7 (со всеми сопутствующими ништяками в виде интегрированного/включённого SELinux) и с созданием для адаптера СМЭВ специального непривилегированного пользователя adapter.

«Enterprise Linux» — на практике обычно (но не всегда, тут есть вариант) означает CentOS. Все достоинства которого сводятся к совместимости с RHEL и бесплатности.

Сюда же следует посчитать калькуляции Irsi (старательно открещивающегося от выступлений на ЛОРе лет двадцать тому назад) на тему цены владения аналогичным проектом.

И моё мнение о том, что в деле выбора национальной платформы следует отталкиваться от PMS (Package Manager Specification) ориентироваться на калькулятор (Calculate Linux).

Устанавливаю скачанный с сайта Оракла и проверенный (!) пакет:

# yum install ./jdk-8u*-linux-x64.rpm

После чего перехожу к «установке» КриптоПро. Описание процесса загрузки/проверки в предыдущей статье. В начальном приближении использую ознакомительную версию лицензии.

Установка выполняется запуском «pesky» (© unpacker.eclass (5) из пакета =app-doc/eclass-manpages-20200213) бинарного файла установщика (всё привычным для погромиздов способом, как в самой распространённой ОС, продаваны подписок (регулярные платежи!) на вредоносное ПО лаборатории касперского жадно потирают ручки), причём запускать его нужно с правами root'а.

Сама «установка» сводится к копированию jar-архивов дистрибутива в каталог JRE.

# unzip jcp-2.0.40502.zip && cd jcp-2.0.40502 && sh setup_console.sh /usr/java/jdk1.8.0_251-amd64/jre

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

При этом, что самое смешное, «устанавливаются» далеко не все *необходимые* для работы инструменты. Например оболочка для запуска гуя настройки (ControlPane.sh). Которую можно отдельно ручками скопировать в ~/bin/.

О применимости последнего скромно умолчим (потому что уже очень давно во всех дистритубивах GNU/Linux категорически не рекомендуется запускать X Window System с правами root'а).

С привлечением толики послезнания: втыкаю стандартный GUI (зачем гуй на сервере? или просто инерция импринтинга виндавса в опыте разработчиков?)…

# yum groupinstall "Server with GUI"

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

Данная «установка» неработоспособна и практически бесполезна.

Такой вот «лидер российского рынка». Надеюсь, все оценили.

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

# cd /opt && tar zxf /root/jdk-8u*-linux-x64.tar.gz

Отсюда же, кстати, следует вывод о неприменимости свободной реализации (потому что она устанавливается стандартным и правильным с точки зрения логики компоновки дистрибутива образом из пакета). Здесь же из закромов личного опыта можно извлечь воспоминания о проблемах при использовании программных решений, аналогичных рассматриваемому, совместно с реализациями жабы, отличными от оригинальной (и это закономерно: если в ППО акцент разработки ставится на чтоб работало, то в СПО — на том, чтобы работало правильно).

По этому поводу не буду подавлять соблазн и процитирую Прекрасное с просторов интернетов:

I had a problem so I thought I would use Java. Now I have ProblemFactory.

Повторяю процесс установки КриптоПро с костыльно воткнутой оригинальной жабой:

# unzip jcp-2.0.40502.zip && cd jcp-2.0.40502 && sh setup_console.sh /opt/jdk1.8.0_251/jre

Попутно отмечаю, что с таким способом «установки» (прибитая в пути к JRE версия жабы с копированием по оному файлов КриптоПро) совершенно непонятен процесс обновления [жабы], которые случаются… достаточно регулярно. Например в случае популярного проекта PHP минорные обновления выходят примерно раз в месяц. И отслеживать которые, в случае самостоятельной установки, нужно тоже самостоятельно и вручную.

Возвращаюсь к «установке» и [ересью больше, ересью меньше…] выдаю права непривилегированному пользователю, попутно наслаждаясь зияющими высотами культуры разработки многопользовательских приложений. На этот раз всё вроде бы на месте.

# chown -R adapter:adapter /opt/jdk1.8.0_251/jre/.systemPrefs

Можно втыкать контейнер с сертификатом и ключом, а также необходимыми сертификатами ЦА. Вообще-то согласно изначальной задумке модель предусматривала использование устройств типа «Рутокен», но… эпопеей фактической поддержки фрюниксов разработчиками устройств, заявляющими совместимость (!), можно насладиться здесь. Поэтому с учётом корректив, внесённых Практикой — компромиссный вариант (hdimagestore).

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

И путь к файлам: /var/opt/cprocsp/keys/adapter/

При этом необходимо помнить о таком следствии использования платформы Java, как необходимость импорта сертификатов Центров Авторизации в специальное хранилище с помощью отдельной утилиты (/opt/jdk1.8.0_251/jre/bin/keytool):

$ keytool -keystore cacerts -importcert -alias <alias> -file <filename>.cer

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

В pesky бинарном установщике закономерным образом отсутствует предварительная проверка наличия стандартных утилит. А в Enterprise Linux 7 свершился production дебют поделия Леннарта с потерей целого ряда стандартных и привычных утилит (то же самое только иначе, с исправлением «фатального недостатка»). Исправляем это:

# yum install net-tools

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

$ mkdir smev3 && cd smev3 && sh smev_adapter_v.3.1.8.run

Завершающим этапом установки (столько ересей наворочено, что уже всё равно) — копирование внешних зависимостей адаптера по указанному пути.

# cp commons-logging-1.1.jar /opt/jdk1.8.0_251/jre/lib/ext/

# cp xmlsec-1.4.5.jar /opt/jdk1.8.0_251/jre/lib/ext/

И, собственно то, ради чего оно городилось, то есть запуск.

$ cd smev3 && ./adapter.sh start

Причём попытка запуска с использованием полного пути:

$ /home/adapter/smev3/adapter.sh start

совершенно внезапно не работает. Такой вот памятник общей культуре разработки.

После установки нужно осуществить настройку. Для чего [СЮРПРИЗ] предлагается использовать административную web-консоль (то есть настройка требует запуска приложения, с учётом давней моды из мира баз данных — практически стандарт). Всей «защиты» которой — нестандартный порт (парольный механизм авторизации, да с использованием протокола http — это неспортивно).

Теперь необходимо сделать организационное отступление и зарегистрировать Информационную Систему у оператора СМЭВ.

После завершения регистрации он предоставляет символьную строку идентификатора (т.н. «мнемонику»).

Без задания этой строки настройка практически невозможна.

Интерфейс к меню настройки спрятан за тремя горизонтальными линиями в левом верхнем углу ☺

Как у всякого уважающего себя параноика, умолчательное действие локального пакетного фильтра для цепочки OUTPUT установлена в DROP.

Для успешного завершения данного этапа настройки необходимо разрешить сетевой доступ к http://smev.gosuslugi.ru/ (в руководстве администратора почему-то описан в разделе Windows ☺).

Ну и, с привлечением послезнания и чтобы два раза не вставать: остальные потребные сетевые доступы согласно ЧаВО (адреса в зависимости от используемого контура). Полный список необходимых разрешений:

• smev.gosuslugi.ru порт 80/tcp (на момент написания статьи в списке актуальных адресов/подключений почему-то отсутствует);
• порт 7500/tcp (для случая использования схем 1.1. и 1.2);
• порт 5000/tcp (для случая использования схемы 1.3);
• порт 8580/tcp — СГКТ;
• + при необходимости FTP.

Про причины живучести и очередного воскрешения протокола FTP, за запрет на использование которого не первый год бьются профессионалы от кагбы «информационной безопасности», хочется вспомнить наблюдение с ЛОРа:

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

• - 3 дохлых кота
• - freeBsd
• - php
• - неопопзнанные скелет кентавра

wfrr (*) (28.02.2010 12:23:22)

После чего необходимо задать соответствующего криптопровайдера:

• «DIGT» для КриптоПро CSP + Trusted Java 2.0;
• «JCP2» для КриптоПро JCP 2.0.

Под псевдонимами сертификата и приватного ключа понимается идентификатор контейнера (hdimagestore) в котором они располагаются. При этом смысл двукратного задания одной и той же строки от меня ускользает.

Прекраснее только «импортозамещательное» умолчательное значение хранилища сертификатов («реестр» Microsoft Windows).

Человекочитаемого способа получения строки идентификатора контейнера [в случае использования платформы GNU/Linux (такая вот «кроссплатформенность»)] мне не известно. Но если, после настройки КриптоПро и выбора правильного криптопровайдера, ткнуться в кнопку «Проверка подписи», сам адаптер подскажет список доступных.

Контрольное нажатие кнопки «Проверить подпись» показывает доступность провайдера, наличие сертификата и ключа.

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

ЗЫ: Да, для вдохновения при выяснении причин наблюдаемых ошибок рекомендуется использовать журнал.

Файл (в предполагаемой структуре) /home/adapter/smev3/logs/smev-adapter.log (запись журналов по FHS в /var/log/? не, не слышали… причём тенденцию можно наблюдать как бы не на всех (!) виденных мной жаба-поделиях)

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

Конфигурационный файл, в котором, справедливости ради, практически ничего интересного — /home/adapter/smev3/config.ini

Основной задачей эксплуатации является отслеживание сроков действия закрытого ключа и сертификата.

---

ЗЫ: На десерт в качестве иллюстрации инфраструктурных проблем «импортозамещения» полезно напомнить статью о работоспособности KVM.

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