Отчет

Апробация Hyperledger Fabric v.1.4.2

1. Установка и настройка HLF - 1.4.2 6

1.1 Установка под ОС Ubuntu 6

1.2 Установка под ОС AstraLinux 8

1.3 Установка под ОС CentOS 8

1.4 Установка под ОС RHEL 8

1.5 Установка под ОС Windows 8

2. Апробация HLF - 1.4.2 согласно ФТТ. 13

2.1.1 - Способность платформы к реализации различной бизнес-логики 13

2.1.2 - Процедура развёртывания 21

2.1.3 - Наличие механизмов администрирования 25

2.1.4 - Наличие помощи и поддержки 25

2.1.5 - Возможности интеграции 26

2.1.6 - Операционные системы 32

2.1.7 - Контейнеризация 33

2.1.8 - Оркестровка 33

2.1.9 - Язык реализации 35

2.1.10 - Консенсус 37

2.1.11 - Метрические характеристики платформы 38

2.1.12 - Администрирование перечня участников сети 40

2.1.13 - Должна быть возможность разграничения полномочий участников сети 41

2.1.14 - Взаимодействие с документами средствами платформы 42

2.1.15 - Управление сертификатами и подписями 43

2.1.16 - Поддержка смарт-контрактов 46

2.1.17 - Механизмы CI/CD 48

2.1.18 - Логирование 48

2.3.1.1.1 - ИБ1. Для идентификации пользователей при доступе каждому пользователю должен быть назначен уникальный персональный идентификатор 50

2.3.1.1.2 - ИБ1-1. Должна поддерживаться взаимная идентификация узлов взаимодействия при подключении к платформе 60

2.3.1.1.3 - ИБ2. Доступ пользователей должен осуществляться посредством парольной аутентификации 62

2.3.1.1.4 - ИБ3. Должна обеспечиваться защита обратной связи при вводе аутентификационной информации; ИБ30-4. Во время сеанса авторизации пользователя пароль должен быть либо скрыт маской либо не отображаться на экране 63

2.3.1.1.5 - ИБ4. Локальная парольная политика должна удовлетворять требованиям 64

- 2.3.1.1.6 - ИБ5. Централизованное для каждого узла управление учетными записями пользователей должно осуществляться путем применения возможностей платформы 65

2.3.1.1.7 - ИБ6. Возможность интеграции с существующей системой управления идентификационными данными 65

- 2.3.1.1.8 - ИБ7. Авторизация пользователей на доступ должна производиться только после прохождения процедур идентификации и аутентификации 66

2.3.1.1.9 - ИБ8. Доступ пользователей должен осуществляться посредством аутентификации по сертификату пользователя и паролю 66

2.3.1.2.1 - ИБ9. Должна использоваться система ролевого управления доступом для управления правами доступа пользователей 67

2.3.1.2.2 - ИБ9-1. Учётные записи использующиеся в процессе работы платформы должны быть персонифицированы 68

2.3.1.2.3 - ИБ9-2. Механизмы управления доступом должны быть реализованы как на уровне UI, так и при обращении к API 71

2.3.1.2.4 - ИБ10. Наличие возможности определения уровня грануляции ролевой модели 73

2.3.1.2.5 - ИБ11. Наличие возможности управления ролями на основе групп 75

2.3.1.2.6 - ИБ12. Поддержка возможности наследования прав доступа 76

2.3.1.2.7 - ИБ13. Подсистема разграничения доступа должна позволять предоставлять права доступа в минимально необходимом объеме 76

2.3.1.2.8 - ИБ14. Должен быть ограничен доступ к интерфейсу администрирования, конфигурационным и временным файлам 77

2.3.1.2.9 - ИБ15. Анонимное подключение должно быть запрещено 81

2.3.1.2.10 - ИБ16. Должен обеспечиваться запрет действий пользователей до прохождения процедуры идентификации и аутентификации 82

2.3.1.2.11 - ИБ17. Должно обеспечиваться разграничение доступа между компонентами 82

2.3.1.2.12 - ИБ18. Должно обеспечиваться ограничение неуспешных попыток входа 83

2.3.1.2.13 - ИБ19. Должна обеспечиваться автоматическая блокировка сессии после установленного периода неактивности (бездействия), восстановление сессии должно осуществляться только после повторной идентификации и аутентификации пользователя 83

2.3.1.3.1 - ИБ20. Наличие механизмов фиксации фактов нарушения ИБ и других связанных с безопасностью событий 84

2.3.1.3.2 - ИБ21. Должен быть предусмотрен централизованный интерфейс для работы с журналами событий безопасности 85

2.3.1.3.3 - ИБ22. Подсистема регистрации и учета событий ИБ должна обеспечивать перечень событий 88

2.3.1.3.4 - ИБ23. Журналы регистрации и учета событий ИБ должны храниться в течение заданного периода времени 90

2.3.1.3.5 - ИБ24. При заполнении установленного процента объема памяти, выделенного для хранения журналов регистрации событий ИБ, должно выдаваться соответствующее предупреждение 90

2.3.1.3.6 - ИБ25. При заполнении установленного процента объема памяти, выделенного для хранения журналов регистрации событий ИБ, должна производиться перезапись событий 90

2.3.1.3.7 - ИБ26. Журналы событий ИБ должны быть защищены от несанкционированного просмотра и внесения изменений 91

2.3.1.3.8 - ИБ27. Системное время должно иметь возможность синхронизации с единым доверенным источником (поддержка NTP) 91

2.3.1.3.9 - ИБ28. Должна поддерживаться интеграция с СМУИБ Arcsight (поддержка syslog) 91

2.3.1.4.1 - ИБ29. Должна поддерживаться совместная работа с антивирусным программным обеспечением 92

2.3.1.4.2 - ИБ30. Должна быть возможность интеграции с MaxPatrol 92

2.3.1.4.3 - ИБ30-1. Контроль параметров конфигурации сканером защищенности MaxPatrol не должен оказывать существенного влияния на работоспособность 93

2.3.1.4.4 - ИБ30-2. При невозможности интеграции с MaxPatrol должна быть дана оценка отсутствия оказания существенного влияния на работоспособность платформы 93

2.3.1.4.5 - ИБ30-3. Хранение паролей должно осуществляться в зашифрованном виде 93

- 2.3.1.4.7 - ИБ30-5. Должен поддерживаться механизм валидации подлинности участников информационного обмена, в том числе пользователей и систем использующихся для автоматизации процессов 94

- 2.3.1.4.8 - ИБ31. Эксплуатационная документация должна включать информацию о необходимых для функционирования сетевых параметрах (порт, протокол) 94

- 2.3.1.4.9 - ИБ32. Все пароли по умолчанию для встроенных учетных записей должны иметь возможность замены, а встроенные учетные записи возможность блокировки 94

2.3.1.4.10 - ИБ33. Настройки по умолчанию, которые могут быть использованы для несанкционированного доступа, должны иметь возможность замены 95

2.3.1.4.11 - ИБ34. Должна обеспечиваться своевременная установка пакетов обновлений, по мере их публикации разработчиками 95

2.3.1.5.1 - ИБ35. Обеспечение контроля целостности на уровне программных компонент и файлов конфигураций 96

2.3.1.5.2 - ИБ35-1. Обеспечение контроля целостности информации, содержащейся в блоках 96

2.3.1.6.1 - ИБ36. Должна иметься возможность реализации в отказоустойчивом исполнении 96

2.3.1.6.2 - ИБ36-1. Должна быть обеспечена высокая доступность с заданными параметрами доступности 97

2.3.1.6.3 - ИБ37. Эксплуатационной документацией должны быть определены параметры резервного копирования 97

2.3.1.7.1 - ИБ38. Должно обеспечиваться безопасное сетевое взаимодействие (возможность фильтрации) между компонентами 97

2.3.1.7.2 - ИБ39. Должно обеспечиваться безопасное сетевое взаимодействие (возможность фильтрации) с внешними системами 98

2.3.1.7.3 - ИБ40. Ограничение возможности аутентификации на основе IP-адреса клиента 99

2.3.1.7.4 - ИБ41. При организации доступа из сети Интернет должна поддерживаться возможность обработки информации в разных сегментах сети (разделения серверов на Front-End и Back-End) 99

2.3.1.7.5 - ИБ42. Отсутствие неотключаемых функций взаимодействия с сетью Интернет 99

- 2.3.1.8.1 - ИБ43. Пароли (ключи) должны храниться и передаваться в зашифрованном виде 100

2.3.1.8.2 - ИБ43-1. Должна быть обеспечена возможность проверки электронной подписи/сертификата узла или пользователя 100

- 2.3.1.8.3 - ИБ44. Возможность хранения технических реквизитов (конфигурационных файлов) в зашифрованном виде 101

2.3.1.8.4 - ИБ45. Должно обеспечиваться шифрование канала связи на уровне доступа пользователя 101

- 2.3.1.8.5 - ИБ46. Должно обеспечиваться шифрование канала связи при внутрисистемном взаимодействии компонент 102

2.3.1.8.6 - ИБ47. Возможность интеграции с существующей инфраструктурой открытых ключей. 102

2.3.1.8.7 - ИБ48. Должно обеспечиваться хранение ключей шифрования на отчуждаемом носителе 102

- 2.3.1.8.8 - ИБ49. Возможность генерации сертификата пользователя на пользовательском узле блокчейн сети 103

2.3.2.1 - ИБ201. Возможность интеграции с брокерами очередей 103

2.3.2.2 - ИБ206. Анализ возможности сегрегации доступа к компонентам платформы 104

2.3.2.3 - ИБ207. Возможность обезличивания персональных данных методом замены на идентификаторы 104

2.3.2.4 - ИБ208. Платформа должна обеспечивать изоляцию подключения к узлам и использование данных посредством PKI 105

2.4.1 - Требования к каналам связи 105

2.4.2 - Требования к аппаратному обеспечению 106

2.4.3 - Поддержка 109

2.4.4 - Коэффициент технического использования 110

2.5.1 - Вендоры компонентов платформы 111

2.5.2 - Отсутствие ECCN 111

3. Перечень синтетических бизнес-решений. 112

3.1 Hyperledger Explorer 112

3.2 Реестр организаций 112

4. Дополнительная информация. 112

1. Установка и настройка hlf - 1.4.2

Установка при помощи Ansible скрипта предполагает наличие машины с которой будет производиться синхронизация крипто материала между остальными узлами и развертывание необходимых сервисов.

1.1 Установка под ос Ubuntu

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

Для этого установим Ansible и сгенерируем ssh ключ.

Установка Ansible:

sudo apt update

sudo apt install software-properties-common

sudo apt-add-repository -yes -update ppa:ansible/anslble

sudo apt install ansible

Генерация ключа ssh:

ssh-keygen

После ввода этой команды вы должны увидеть следующий вывод:

Generating public/private rsa key pair.

Enter file in which to save the key (/your_home/.ssh/id_rsa):

Нажмите Enter для сохранения пары ключей в директорию .ssh/ внутри вашей домашней директории (Данные действия предполагают, что на данной машине отсутствуют другие ключи ssh).

Вы должны увидеть следующий вывод:

Enter passphrase (empty for no passphrase):

Оставляем это поле пустым и жмем Enter. Для подтверждения тоже жмем Enter.

Your identification has been saved in /your_home/.ssh/id_rsa.

Your public key has been saved in /your_home/.ssh/id_rsa.pub.

The key fingerprint is:

a9:49:2e:2a:5e:33:3e:a9:de:4e:77:11:58:b6:90:26 username@remote_host

The key's randomart image is:

+--[ RSA 2048]----+

| ..o |

| E o= . |

| o. o |

| .. |

| ..S |

| o o. |

| =o.+. |

|. =++.. |

|o=++. |

+-----------------+

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

ssh-copy-id user@192.168.0.119

где user - пользователь с доступом к sudo на удалённой машине.

192.168.0.119 - IP адрес машины.

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

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

При помощи редактора nano открываем файл sudoers следующей командой:

sudo nano /etc/sudoers

Находим в файле строку:

%sudo ALL=(ALL;ALL) ALL

Меняем её на следующую:

%sudo ALL=(ALL;ALL) NOPASSWD: ALL

Необходимо сохранить файл, для этого жмём сочетание клавиш Ctrl+x подтверждаем действие вводом Y и enter.

Следующая команда откроет необходимые для блокчейн сети порты и активирует фаервол.

sudo ufw allow 22 ; sudo ufw allow 80 ; sudo ufw allow 4000 ; sudo ufw allow 7050 ; sudo ufw allow 7051 ; sudo ufw allow 2376 ; sudo ufw allow 9092 ; sudo ufw allow 2181 ; sudo ufw allow 2888 ; sudo ufw allow 3888; sudo ufw allow 8080 ; sudo ufw enable

После выполнения будет выведено предупреждение о возможном нарушении работы ssh и запрос подтверждения операции. Необходимо дать согласие.

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

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

git clone https://github.com/Altoros/Ansible-Fabric-Starter.git

Переходим в каталог с скриптами:

cd Ansible-Fabric-Starter

Открываем любым текстовым редактором файл с названием hosts_raft.yml

Для примера используем редактор nano.

nano hosts_raft.yml

В открывшемся файле находим следующие строки:

ansible_host: 192.168.0.157

ansible_user: user

Меняем их для каждой организации (в файле org1,org2,org3) в соответствии с IP адресами машин на которых будет произведено развертывание и их пользователями.

Сохраняем файл сочетанием клавиш Ctrl+x подтверждаем действие вводом Y и enter.

Теперь запустим скрипты для развёртывания сети следующими командами:

ansible-playbook install-python.yml -i hosts_raft.yml

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

ansible-playbook install-dependencies.yml -i hosts_raft.yml

Установка зависимостей обычно занимает много очень времени.

ansible-playbook config-network.yml -i hosts_raft.yml

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