Центр электронного взаимодействия "Тундук"

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

======Руководство по переходу с X-Road 6 на X-Road 7======

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

Изменения, перечисленные в разделе критических изменений, требуют действий со стороны администратора. Изменения, перечисленные в разделе примечательных новых функций, не требуют прямого действия, но позволяют расширить возможности X-Road. Менее важные функции и исправления ошибок, включенные в этот выпуск, не перечислены в этом руководстве. Вместо этого их можно найти в примечаниях к выпуску X-Road 7.0.0.

Все изменения можно просмотреть на официальной странице X-Road - https://x-road.global/releases

=====2 Критические изменения=====
====2.1 Изменения конфигурации службы====
====2.1.1 Общие положения====
В предыдущих версиях X-Road переопределения конфигурации службы хранились в /etc/xroad/services/local.conf. Файл может содержать переменные среды и исполняемый код, что является проблемой безопасности.

В X-Road 7 изменен механизм переопределения конфигурации службы. Переопределения хранятся в неисполняемом файле /etc/xroad/services/local.properties. Файл может содержать только переопределения конфигурации предопределенных переменных среды, а все остальное игнорируется. Кроме того, формат и имена переменных среды X-Road будут другими. Начиная с версии 7.0.0 все переменные имеют префикс XROAD_. Например, разница в настройке выделения памяти для прокси в X-Road 6 и X-Road 7:

===X-Road 6===
===/etc/xroad/services/local.conf===
<code>
PROXY_PARAMS="$PROXY_PARAMS -Xms200m -Xmx2000m "
</code>

===X-Road 7===
===/etc/xroad/services/local.properties===
<code>
XROAD_PROXY_PARAMS=-Xms200m -Xmx2000m
</code>

Вот список переменных среды, связанных с X-Road, и их имена в разных версиях X-Road.
|**Старые имена (X-Road 6)**|**Новые имена (X-Road 7)**|
|XROAD_PARAMS|XROAD_PARAMS|
|SIGNER_PARAMS|XROAD_SIGNER_PARAMS|
|ADDON_PARAMS|XROAD_ADDON_PARAMS|
|CONFCLIENT_PARAMS|XROAD_CONFCLIENT_PARAMS|
|CONFPROXY_PARAMS|XROAD_CONFPROXY_PARAMS|
|JETTY_PARAMS|XROAD_JETTY_PARAMS|
|MONITOR_PARAMS|XROAD_MONITOR_PARAMS|
|OPMON_PARAMS|XROAD_OPMON_PARAMS|
|PROXY_PARAMS|XROAD_PROXY_PARAMS|
|PROXY_UI_API_PARAMS|XROAD_PROXY_UI_API_PARAMS|
|SIGNER_CONSOLE_PARAMS|XROAD_SIGNER_CONSOLE_PARAMS|
|VERIFY_IDMAP_PARAMS|XROAD_VERIFY_IDMAP_PARAMS|

Несмотря на изменения, при обновлении с версии 6 до 7 все переопределения, определенные в /etc/xroad/services/local.conf, будут продолжать работать, как и раньше, включая старые имена переменных среды. Однако, начиная с X-Road 7.0.0, резервные копии больше не содержат файл /etc/xroad/services/local.conf, вместо этого будет включен файл /etc/xroad/services/local.properties. Это означает, что в случае восстановления Центрального сервера или Сервера безопасности из резервной копии все переопределения локальной конфигурации, определенные в /etc/xroad/services/local.conf, будут потеряны. Пользовательский интерфейс Security Server и сценарии командной строки, связанные с резервным копированием, предупреждают об этом.

Настоятельно рекомендуется перенести все переопределения конфигурации в новый файл /etc/xroad/services/local.properties при обновлении с версии 6 до 7. В переносе нет автоматизации, поэтому перенос переопределений конфигурации должен выполняться вручную администратор. Миграция включает изменение имен переменных на новый формат с префиксом XROAD_ и обновление значений в соответствии с новым форматом свойств. В случае, если старый файл конфигурации /etc/xroad/services/local.conf содержит что-то еще, кроме модификаций переменных среды, связанных с X-Road, изменения должны обрабатываться каким-либо другим способом, поскольку новый механизм переопределения конфигурации их не поддерживает. .

Кроме того, новые и старые файлы конфигурации могут сосуществовать рядом. Когда существуют файлы local.conf и local.properties, сначала применяется local.properties, а затем — local.conf. Однако local.properties может добавлять только новые переменные (XROAD_*), а local.conf может изменять любые части конфигурации. В результате значения, определенные в local.conf, перезаписывают значения, определенные в local.properties, если одно и то же свойство определено в обоих файлах. Однако непересекающиеся значения, определенные в local.properties, по-прежнему применяются. Кроме того, если в local.conf используются как старые, так и новые имена переменных (например, SIGNER_PARAMS, XROAD_SIGNER_PARAMS), применяется новая переменная. Например:


**/etc/xroad/services/local.properties**

<code>
XROAD_SIGNER_PARAMS=-Dprop1=newValue1 -Dprop2=newValue2
</code>

**/etc/xroad/services/local.conf**

<code>
SIGNER_PARAMS="$SIGNER_PARAMS -Dlegacy=true"
XROAD_SIGNER_PARAMS="$XROAD_SIGNER_PARAMS -Dprop1=oldValue1 -Dlegacy=false"
</code>

Результирующие значения для различных свойств, связанных с XROAD_SIGNER_PARAMS:

<code>
prop1=oldValue1
prop2=newValue2
legacy=false
</code>


<color #ed1c24>**В X-Road 7 файл /etc/xroad/services/local.properties должен содержать одну переменную среды на строку, а свойства, связанные с этой переменной, нельзя разбивать на несколько строк с помощью «\».**</color>

Поддерживается:
<code>
XROAD_SIGNER_PARAMS=-Xms50m -Xmx200m
XROAD_PROXY_PARAMS=-Xms200m -Xmx2000m
</code>

<color #ed1c24>**НЕ поддерживается:**</color>

<code>
XROAD_SIGNER_PARAMS=-Xms50m \
-Xmx200m
XROAD_PROXY_PARAMS=-Xms200m \
-Xmx2000m
</code>

====2.1.2 Действия по переносу конфигурации службы====
1. После обновления Security Server до версии 7.0.0 подключитесь к серверу с помощью терминала командной строки. Проверьте, есть ли файл /etc/xroad/services/local.conf. Если нет, то мигрировать нечего, и вы можете пропустить остальные шаги. Если есть, проверьте содержимое файла, например. cat /etc/xroad/services/local.conf 
Ниже приведен пример вывода.

**/etc/xroad/services/local.conf**
<code>
SIGNER_PARAMS="$SIGNER_PARAMS -Xms50m -Xmx200m"
JAVA_HOME="/usr/lib/jvm/java-1.11.0-openjdk-amd64"
</code>

2. Первый SIGNER_PARAMS можно легко перенести в новый файл свойств, см. ниже. 
Вторая строка с JAVA_HOME должна обрабатываться вне файлов конфигурации X-Road, Например, переместите его в переменную среды операционной системы. Либо просто удалите из файлов конфигурации. 

**/etc/xroad/service/local.properties**
<code>
XROAD_SIGNER_PARAMS=-Xms50m -Xmx200m
</code>

3. После того, как переменные были перенесены, удалите старый файл конфигурации, например. rm /etc/xroad/services/local.conf и перезапустите службы xroad-* или хост-сервер Security Server.

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

К сожалению, изменения в Сервере безопасности обратно несовместимы. Это означает, что файлы резервных копий, созданные на сервере безопасности X-Road 6, не могут быть восстановлены на сервере безопасности X-Road 7. Однако изменения в Центральном сервере обратно совместимы.

Перед обновлением Security Server сделайте резервную копию с помощью других средств. Метод зависит от вашей платформы. Для виртуальных машин стандартной является возможность создания моментальных снимков. Серверы на базе облачных технологий обычно имеют метод создания моментальных снимков содержимого диска. Если обновление сервера безопасности по какой-то причине не удастся, у вас будет возможность восстановить прежнее состояние.

====2.3 Архивирование журналов сообщений перенесено в отдельный процесс====
Архивирование журналов сообщений сервера безопасности было перенесено в отдельный процесс xroad-addon-messagelog.service, который регистрируется в /var/log/xroad/messagelog-archiver.log. Системы мониторинга должны быть настроены таким образом, чтобы учитывать новый сервис и файл журнала в дополнение к старым.

=====3 Примечательные новые возможности=====
====3.1 Шифрование данных в состоянии покоя====
В X-Road 7.0.0 будут введены новые функции безопасности для защиты данных в состоянии покоя на сервере безопасности. К новым функциям относятся:

Шифрование файлов резервных копий
Проверка целостности файлов резервных копий при загрузке файлов резервных копий и перед запуском восстановления
Шифрование полезной нагрузки сообщений в базе данных журнала сообщений
Зашифрованные архивы журнала сообщений
Группировка архивов журналов сообщений по членам или подсистемам.
Регистрация сообщений может быть полностью отключена
Данные, экспортируемые и импортируемые в/из Security Server, могут быть зашифрованы и/или подписаны с помощью GnuPG. Подписание и шифрование необязательны - можно настроить сервер безопасности таким образом, чтобы шифрование не производилось.

Шифрование, подписание, расшифровка и проверка данных выполняются путем запуска внешнего процесса GnuPG и интерпретации сгенерированного результата.  Шифрование базы данных реализовано в коде Java.

Необходимые ключи хранятся в кольцах ключей GPG. Внутренние ключи Security Server, используемые по умолчанию, генерируются автоматически. Ключи для конкретных членов управляются администратором вручную.

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

Новые ключи шифрования на сервере безопасности

{{ :image.png |}}

1. Внутренняя пара ключей GPG
Создается автоматически в процессе инициализации сервера безопасности или обновления версии.
Закрытый ключ используется для:
подписывать файлы резервных копий
подписания файлов архива журнала сообщений, если включено шифрование архива журнала сообщений
расшифровки файлов резервных копий во время восстановления.
Открытый ключ используется для:
шифрования файлов резервных копий, когда включено шифрование резервных копий
шифрования файлов архива журнала сообщений, когда включено шифрование архива журнала сообщений и архивы не шифруются ключом для каждого пользователя
проверки целостности файла резервной копии во время восстановления.
Для внешней проверки целостности файла резервной копии или архива журнала сообщений администратор должен вручную экспортировать открытый ключ.
Затем проверка может быть выполнена с помощью любых стандартных инструментов PGP.
Не включена в резервные копии сервера безопасности

2. Резервное копирование/восстановление ключей GPG
Дополнительные открытые ключи, которые используются для шифрования файлов резервных копий, когда включено шифрование резервных копий.
Создание дополнительных ключей рекомендуется для защиты от потери внутренней пары ключей GPG
Создается вручную администратором сервера безопасности
Соответствующие закрытые ключи:
управляются извне администратором сервера безопасности
могут быть использованы для расшифровки резервных копий вне сервера безопасности, например, в случае потери внутренней пары ключей сервера безопасности.
По умолчанию включены в резервные копии сервера безопасности.

3. Ключ шифрования базы данных
Ключ шифрования, который используется для шифрования тела сообщения в базе данных журнала сообщений, когда включено шифрование базы данных.
Зашифрованное тело сообщения хранится в новом столбце ciphermessage, а столбец message остается пустым.
Создается вручную администратором сервера безопасности
Включается в резервные копии сервера безопасности, если хранится в /etc/xroad, но не в /etc/xroad/gpghome
Расположение определяется администратором сервера безопасности при включении шифрования базы данных

=====4. Архивные ключи GPG=====
Дополнительные открытые ключи для каждого члена, которые используются для шифрования файлов архива журнала сообщений, когда включено шифрование и группировка архива журнала сообщений.
Ключи зависят от конкретного члена и используются для шифрования архивов, принадлежащих определенному члену.
Соответствующие закрытые ключи управляются администратором сервера безопасности извне.
Закрытые ключи могут быть использованы для расшифровки архивных файлов журнала сообщений за пределами сервера безопасности.
По умолчанию не включается в резервные копии сервера безопасности.

===3.1.1 Шифрование файлов резервных копий и проверка их целостности===
Резервные копии конфигурации сервера безопасности всегда подписываются, но шифрование резервных копий изначально выключено. Если шифрование включено, файлы резервных копий шифруются при их создании и хранятся на диске в зашифрованном виде. Это относится как к автоматически создаваемым, так и к создаваемым пользователем резервным копиям. Когда речь идет о резервных копиях, созданных пользователем, конфигурация применяется к пользовательскому интерфейсу Security Server и API управления REST.

Security Server проверяет целостность архива резервных копий во время операции восстановления. Проверка целостности требует наличия оригинальной пары внутренних ключей Security Server. В случае потери внутренней пары ключей операция восстановления не может быть выполнена в пользовательском интерфейсе или через API, а должна быть выполнена из командной строки с соответствующими опциями, позволяющими пропустить проверку целостности.

Конфигурация резервного шифрования описана в Руководстве пользователя сервера безопасности.

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

В базе данных есть две отдельные колонки для открытого текста (сообщение) и зашифрованного (ciphermessage) тела сообщения. Тело сообщения всегда хранится в одном из двух столбцов в зависимости от конфигурации. Другой столбец остается пустым. Когда шифрование базы данных журнала сообщений включено/выключено, изменение не влияет на уже существующие записи в базе данных. Например, когда включено шифрование базы данных журнала сообщений, все записи после изменения будут зашифрованы и сохранены в столбце ciphermessage. Вместо этого все записи, сохраненные до изменения, останутся в столбце message в виде обычного текста.

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

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

===3.1.3 Шифрование и группировка архива журнала сообщений===
Шифрование и группировка архива журнала сообщений могут быть настроены отдельно. По умолчанию оба параметра отключены. Группировка и шифрование включаются/выключаются на уровне сервера безопасности - они либо включены, либо выключены для всех членов и подсистем. Невозможно включить/выключить ни то, ни другое только для выбранных членов или подсистем.

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

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

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

Шифрование архива журнала сообщений описано в Руководстве пользователя сервера безопасности.

===3.1.4 Регистрацию сообщений можно полностью отключить===
Теперь Security Server можно установить с отключенным аддоном журнала сообщений. Когда аддон журнала сообщений отключен, сообщения не регистрируются, и служба временной метки не требуется. Это необязательный шаг во время установки, но по умолчанию аддон все равно устанавливается. 

====3.3 Возможность установки Security Server без локального сервера PostgreSQL====
Начиная с X-Road 7.0.0, появилась возможность установить сервер безопасности без локального сервера PostgreSQL. Ранее можно было настроить сервер безопасности на использование удаленной базы данных, но локально установленный сервер базы данных PostgreSQL оставался установленным в любом случае. Это дополнительно оптимизирует использование ресурсов сервером безопасности.


====3.4 Возможность изменения PIN-кода на сервере безопасности====
Сервер безопасности позволяет изменить PIN-код, который был выбран при первоначальной настройке. Изменение должно быть выполнено в командной строке с помощью инструмента signer-console. Руководство пользователя консоли Signer Console описывает эту операцию.

====3.5 Запуск сервера безопасности на Java 11 по умолчанию====
Теперь сервер безопасности по умолчанию работает на платформе Java 11. Чтобы перевести существующую установку на Java 11, см. следующие шаги, описанные в Базе знаний X-Road. Сервер безопасности 7.0.0 также отображает используемую версию Java в представлении диагностики пользовательского интерфейса.

====3.6 Улучшения в диагностике====
В новом Security Server улучшено представление диагностики в пользовательском интерфейсе. 

Диагностика теперь показывает информацию о версии Java
Статус диагностики теперь показывает, может ли TSA обрабатывать запросы временной метки. Ранее статус показывал только успешность TCP-соединений с TSA.

====3.7 Обновление версии возможно только с двух предыдущих версий====
Официальная политика поддержки установок X-Road заключается в том, что обновление с двух предыдущих версий тестируется основной командой разработчиков и гарантированно работает. X-Road 7 реализует эту политику в инсталляционных пакетах таким образом, что обновление с трех и более версий не разрешено напрямую, а должно выполняться поэтапно. Например, обновление с 6.24.0 до 7.0.0 не работает напрямую. Поддерживаемый путь - это сначала обновление до 6.26.0, а затем до 7.0.0. Более подробную информацию об этом можно найти в руководстве по установке.

----

Автор Даниил Горбенко
Центр электронного взаимодействия "Тундук"

Инструменты пользователя

Инструменты сайта

Инструменты страницы
