2. Апробация hlf - 1.4.2 согласно фтт.
|
2.1.1 - Способность платформы к реализации различной бизнес-логики |
|
|
Составить синтетический бизнес - процесс. Обозначить ключевые точки синтетического процесса и его артефакты. Составить сценарий работы. Реализовать синтетический бизнес - процесс в виде СБР |
Установить СБР на узлы HLF, проверить, что СБР корректно запустилось и имеет возможность работы по сценарию. Допускается использование нескольких СБР для проведения тестирование из открытых источников сети интернет. |
|
Блокчейн платформа должна предоставлять возможность записи транзакций, осуществлять их мониторинг. СБР - Hyperledger Explorer, осуществление транзакции через Web-интерфейс (API), просмотр лога транзакции. После установки и настройки сети, Hyperledger Explorer запускается на порту 8080
Вход осуществляется по логину и паролю, которые указаны в конфигурации сети. В Hyperledger Explorer по умолчанию есть учетная запись администратора. В данном случае - это admip/adminpw .
После процедуры входа видим следующий интерфейс.
Где предоставляется возможность отслеживания транзакций.
Вкладка получений информации о текущем состоянии сети.
Вкладка просмотра блоков в блокчейн-сети.
Можно получать информацию по каждому из блоков и транзакциям.
Интерфейс получения перечня успешных транзакций.
Чейнкоды по разным организациям.
Интерфейс просмотра списка каналов.
Осуществим авторизацию в веб-клиенте, через который осуществим транзакцию.
По запросу наблюдаем значение транзакции.
Также, наблюдаем эту информацию в списке транзакций.
|
|
|
2.1.2 - Процедура развёртывания |
|
|
Подготовить в виде описания прозрачный и понятный процесс развёртывания платформы
|
Предоставлена последовательность действий необходимая и достаточная для развёртывания платформы под различные операционные системы (Ubuntu, Centos, RHEL, AstraLinux, Windows).
|
|
Ubuntu:
Первым делом необходимо настроить машину с которой будет производится развертывание. Для этого установим Ansible и сгенерируем ssh ключ.
Установка Ansible: sudo apt update sudo apt install software-properties-common sudo apt-add-repository --yes --update ppa:ansible/ansible 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 2356 ; 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 После выполнения этой команды блокчейн сеть должна быть развернута и доступна для использования.
Centos:
Отличие от установки на ubuntu заключается в настройке машин на которых будет развернута блокчейн сеть, при этом машину с которой будет производится установка можно не менять.
В Centos редактор nano отсутствует поэтому можно установить его или воспользоваться vi. sudo vi /etc/sudoers %whel ALL=(ALL;ALL) NOPASSWD; ALL #для centOS
Отключаем selinux. sudo vi /etc/sysconfig/selinux Для перехода в режим редактирования нужно нажать i для выхода из него esc, для режима команд : команда для выхода без сохранения q! для сохранения изменений w для выхода q. SELINUX=disabled #меняем строчку Выполняем команду sudo setenforce 0 Далее настраиваем фаервол. sudo firewall-cmd --set-default-zone=trusted
RHEL: Установка на RedHat Enterprice Linux не отличается от процесса установки на Centos.
Astra:
Установка на AstraLinux не отличается от процесса установки на Ubuntu.
Windows: |
|
|
2.1.3 - Наличие механизмов администрирования |
|
|
Подготовить в виде отчёта существующие возможности администрирования платформы
|
Предоставлены механизмы администрирования компонентов платформы, которые включают в себя средства операционной системы, средства обновления чейн-кода и оффчейн приложений. |
|
Для администрирования средствами операционной системы можно воспользоваться:
Для обновления чейнкода, необходимо воспользоваться скриптами обновления. В качестве примера можно привести скрипт: https://github.com/Altoros/Ansible-Fabric-Starter/blob/v1.4.2/chaincode-upgrade.yml Описание шагов по запуску и обновлении чейнкода:
|
|
|
2.1.4 - Наличие помощи и поддержки |
|
|
Подготовить перечень возможностей получения помощи и поддержки по платформе и её компонентам |
Предоставлен перечень сайтов в публичной сети интернет, сервисных центров, сервисов технического обслуживания и поддержки пользователей. |
|
Основные ресурсы, на которых возможно получение технической поддержки и поиск решения проблем по установке, администрирования и эксплуатации HLF.
Официальная документация: https://hyperledger-fabric.readthedocs.io/en/release-1.4/ mailing list: https://lists.hyperledger.org/g/fabric RocketChat: https://chat.hyperledger.org/ https://chat.hyperledger.org/channel/fabric-questions StackOverflow: https://stackoverflow.com/questions/tagged/hyperledger-fabric Telegram: https://t.me/hyperledger_russia https://t.me/hlbootcamp https://t.me/rosblockchain_chat |
|
|
2.1.5 - Возможности интеграции |
|
|
Составить сценарий интеграции платформы с какой-либо существующей системой Реализовать данный сценарий в рамках СБР Предоставить перечень заявленных вендором платформы вариантов интеграции |
Составить сценарий интеграции платформы с какой-либо существующей системой Реализовать данный сценарий в рамках СБР Предоставить перечень заявленных вендором платформы вариантов интеграции |
|
Интеграция OpenLdap с Hyperledger Fabric CA.
Установка OpenLDAP & phpLDAPadmin Для установки нам понадобится bash скрипт имеющий следующее содержание: #!/bin/bash -e
docker run -p 8000:389 --name ldap-service --hostname ldap-service --detach osixia/openldap:1.1.8 docker run -p 6443:443 --name phpldapadmin-service --hostname phpldapadmin-service --link ldap-service:ldap-host --env PHPLDAPADMIN_LDAP_HOSTS=ldap-host --detach osixia/phpldapadmin:0.9.0
После запуска docker сам скачает образы не найдя их локально. Перед запуском убедитесь что на машине присутствует docker и пользователь может запускать его без sudo. Также убедитесь, что порты 8000 и 6443 открыты. Для отладки была использована машина с одним из пиров. Как только скрипт выведет идентификаторы контейнеров сервис phpLDAPadmin будет доступен на 6443 порте машины, а OpenLDAP на 8000. Логин cn=admin,dc=example,dc=org Пароль admin Теперь необходимо настроить файл конфигурации fabric ca. Найдите ldap в конфигурации и настройте следующим образом:
ldap: enabled: true url: ldap://cn=admin,dc=example,dc=org:admin@192.168.0.140;8000/dc=example,dc=org tls: certfiles: client: certfile: keyfile: attribute: names: ['uid','member','cn'] converters: - name: hf.GenCRL value: attr("uid") =~ "user*"
Замените 192.168.0.140 на ip адрес вашей машины.
В hyperledger fabric присутствуют несколько атрибутов предоставляющих разграничение контроля доступа.
При включении ldap блокируется возможность регистрации пользователей средствами fabric ca, поэтому использование атрибутов связанных с регистрацией не приведёт к желаемому результату. Остальные атрибуты можно присвоить пользователям добавляя в конфигурации к следующим строкам: converters: - name: hf.GenCRL value: attr("uid") =~ "user*" Например:
converters: - name: hf.GenCRL value: attr("uid") =~ "user*" - name: hf.AffiliationMgr value: attr("uid") =~ "mgr*"
Логинимся на сервере phpLdapAdmin.
Переходим
в корневой каталог. Создаём учётную запись create child entry.
Для
теста выбираем Generic: simple security object. Теперь заполняем поля учетной записи.
После нажатия create object учётная запись будет создана.
На этой картинке можно увидеть таким образом созданные мной две учётные записи. Теперь проверим их работоспособность при помощи hyperledger fabric cli исполняя команды внутри контейнера fabric ca.
Команда предполагает, что пользователь залогинится как пользователь с соответствующим логином.
Команда успешно выполнена.
На скрине выполнение команды логина как user1 завершившееся успехом.
Попытка логина как пользователь user123 которого нет на сервере ldap закончилась ошибкой 20, что означает доступ запрещён. |
|
|
2.1.6 - Операционные системы |
|
|
Развернуть платформу на заявленных вендором платформы ОС |
Платформа в базовой конфигурации развернута и функционирует в штатном режиме на операционных системах Ubuntu, Centos, RHEL, AstraLinux, Windows. |
|
Установить и настроить HLF-1.4.2 в базовой конфигурации успешно удалось на операционных системах Ubuntu, Centos, RHEL, AstraLinux, Windows. Подтверждающие скриншоты в пункте №1 - Установка и настройка HLF-1.4.2. |
|
|
2.1.7 - Контейнеризация |
|
|
Развернуть платформу на заявленных вендором вариантах контейнеризации |
Запустить платформу HLF в виде контейнеров Docker на операционных системах. |
|
В пункте №1 описывается как запустить платформу в виде Docker контейнеров. Вывод команды docker ps на узлах сети HLF.
org0
org2
org3
org1
В данной конфигурации HLF 1.4.2. настроена на четырех узлах ( два узла - CentOS, два узла - AstraLinux) на базе Docker контейнеров.
|
|
|
2.1.8 - Оркестровка |
|
|
Развернуть платформу на заявленных вендором вариантах оркестровки Развернуть платформу с использованием корпоративной оркестровки OpenShift |
Ввиду сложности развёртывания платформы для оркестровки (Kubernetes, Openshift) предлагается предоставить доказательство возможности применения обеих оркестровок документально (рекомендуется указать сложности, которые возможны при использовании OpenShift). |
|
Для развертывания HLF на кластере Kubernetes можно воспользоваться следующими решениями:
https://github.com/hyperledger-labs/nephos Он позволяет автоматизированно осуществлять установку на предустановленный кластер. Для локального тестирования можно воспользоваться одноузловым кластером Kubernetes - Minikube. Для установки HLF на Minikube необходимо запустить следующую команду:
PYTHONPATH=. ./nepnos/deploy.py -f ./examples/dev/nephos_config.yaml fabric
Присутствуют различные варианты установки (dev, prod, qa), как на локальный кластер (minikube), так и на production кластер kubernetes.
Можно воспользоваться уже готовыми helm charts для быстрой установки на уже развернутый кластер kubernetes. В данном случае уже нет разницы, одноузловой кластер или production, helm работает через kubectl.
Для добавления репозитория необходимо указать следующую команду: helm repo add stable https://kubernetes-charts.storage.googleapis.com
Для добавления chart и установки HLF-CA helm install stable/hlf-ca --version 1.2.0 --generate-name
Для установки HLF-CouchDB: helm install stable/hlf-couchdb
Для установки HLF-Orderer: helm install stable/hlf-ord
Для установки HLF-Peer: helm install stable/hlf-peer
Задачи настройки и администрирования сети HLF можно также осуществлять посредством helm с написанными yaml-файлами.
OpenShift основан на Kubernetes. Многие принципы установки схожи, особенности и проблемы установки HLF на OpenShift рассмотрены в докладе на RedHat Summit: https://www.redhat.com/files/summit/session-assets/2019/T905A4.pdf
Для запуска на OpenShift и MiniShift дополнительно есть ansible-playbooks: https://github.com/luszczynski/hyperledger-fabric-openshift https://github.com/aldredb/hyperledger-on-openshift
|
|
|
2.1.9 - Язык реализации |
|
|
Реализовать СБР на заявленных вендором платформы языках программирования Выбрать необходимый перечень комбинаций конфигураций ОС\Контейнеризации\Оркестровки Развернуть реализованные версии бизнес-решения на выбранных конфигурациях
|
Предоставить возможность реализации СБР на нескольких языках программирования, предоставить перечень необходимых зависимостей для запуска СБР и их особенности.
|
|
Для разработки СБР в HLF поддерживается четыре языка программирования:
Как пример решения на языке Python: Реестр публичных сведений об организациях. https://github.com/bcgov/TheOrgBook
Запуск осуществляется путем docker-compose, c помощью скрипта ./manage build После процесса сборки и установки необходимых docker-образов и записимосейчас запускается приложение, которое доступно на нескольких портах.
В качестве СБР на JavaScript - Hyperledger Caliper (п.2.1.11) и Hyperledger Explorer (п.2.1.1).
В качестве СБР на Java: https://github.com/IBM/blockchain-application-using-fabric-java-sdk https://github.com/ecsoya/spring-fabric-gateway
На языке Go преимущественно разрабатываются чейнкоды (множество примеров доступно на github) и архитектурные решения (интеграция с Keyclock - п.2.3.1.1.7).
|
|
|
2.1.10 - Консенсус |
|
|
Должны быть описаны предоставляемые платформой алгоритмы консенсуса |
Предоставить перечень поддерживаемых платформой алгоритмов консенсуса с их описанием. |
|
Основным механизмом обеспечения консенсуса в Hyperledger Fabric является алгоритм PBFT. PBFT – механизм на базе голосования. Каждый узел формирует ключ. Любое сообщение, проходящее через узел, подписывается им для проверки. Далее сообщение вновь пересылается другим узлам и проходит проверку. После того как будет достигнуто достаточное количество одинаковых ответов, транзакция считается действительной.
RAFT - это распределенный отказоустойчивый алгоритм консенсуса, который гарантирует, что в случае сбоя система сможет принять решение и обработать запрос клиента. Используется когда сбои рассматриваются с технической точки зрения. Например проблемы с доступом в сеть или выход из строя одного/нескольких узлов сети. В техническом плане Raft - это согласованный алгоритм для управления реплицированной базой данных. https://medium.com/@spsingh559/detail-analysis-of-raft-its-implementation-in-hyperledger-fabric-d269367a79c0
Консенсус на основе Kafka кластера работает следующим образом. Узлы orderer отправляют в Kafka кластер транзакции и получают от него транзакции в том же порядке, так как Kafka кластер представляет собой абстракцию общей очереди. Все orderer создают блоки, когда читают достаточно сообщений, количество или данных из кафки. Кроме того, если транзакция была отправлена, но блок не был создан, и прошло достаточно времени (тайм-аут), то узел-orderer отправляет специальное сообщение в Kafka кластер, которое сообщает всем узлам сети обрезать блок. Это гарантирует, что все orderer обрезают блоки по тайм-ауту, а также что они обрезают одни и те же блоки. Каждый одноранговый узел являющийся лидером подключается к случайному orderer, а затем отправляет запрос, сообщая, из какого индекса блока он хочет получить блоки. Затем - orderer читает блоки из своей файловой системы и отправляет их одноранговому узлу. Когда одноранговый узел получает блоки, он также отправляет их другим одноранговым узлам при помощи встроенных средств синхронизации. На данный момент этот тип консенсуса считается устаревшим. На смену ему в версии 1.4.1 ввели консенсус на основе RAFT т.к. сеть с консенсусом на основе Kafka работала недостаточно быстро. https://stackoverflow.com/questions/52605676/how-hyperledger-fabric-kafka-consensus-works
Соло (устарело в версии 2.0) реализация службы orderer предназначена только для тестирования и состоит только из одного узла orderer. Он устарел и может быть полностью удален в следующей версии. Существующие пользователи Solo должны перейти на сеть Raft с одним узлом, являющуюся эквивалентной. https://hyperledger-fabric.readthedocs.io/en/release-2.0/orderer/ordering_service.html
|
|
|
2.1.11 - Метрические характеристики платформы |
|
|
Предоставить метрические характеристики платформы:
|
Требуется предоставить скриншоты с стандартными метрическими характеристиками, а также показать возможность сбора дополнительной информации (большое количество метрических данных) посредством таких средств, как Prometeus и StatsD. |
|
Для запуска сети с настроенным Prometeus для получения данных можно воспользоваться набором скриптов: https://github.com/yeasy/docker-compose-files/tree/master/hyperledger_fabric
Запуск осуществляется следующим образом:
Можно осуществить ряд запросов и посмотреть на результаты.
Проверим версию Hyperledger Fabric
График процессов на каждом из пиров.
Для агрегации данных посредством StatsD необходимо в конфигурационных файлах пира (core.yaml) и ордерера (orderer.yaml) прописать адрес демона StatsD:
Пример для пира:
metrics: provider: statsd statsd: network: udp address: 127.0.0.1:8125 writeInterval: 10s prefix: peer-0 Пример для ордерера:
Metrics: Provider: statsd Statsd: Network: udp Address: 127.0.0.1:8125 WriteInterval: 30s Prefix: org-orderer
Далее данные будут передаваться по указанному адресу. Для визуализации можно использовать Graphite или же обеспечить экспорт в Prometeus с использованием программного обеспечения prometheus-statsd-exporter. Для Grafana есть подготовленный модуль: https://grafana.com/grafana/dashboards/10716 |
|
|
2.1.12 - Администрирование перечня участников сети |
|
|
Предоставить способ или способы администрирования перечня участников сети |
Требуется предоставить описание технического решения и подтверждающие скриншоты. |
|
В официальной документации есть описание данного процесса. https://hyperledger-fabric.readthedocs.io/en/release-1.4/channel_update_tutorial.html Этот туториал сосредоточен исключительно на интеграции новой организации, но тот же подход может быть принят при выполнении других обновлений конфигурации канала (например, при обновлении политик).
При установке с помощью Ansible скрипта доступен экспериментальный способ, предназначенная для добавления новых организаций и каналов в работающую сеть, ранее развернутую с помощью ansible-fabric-starter в режиме kafka-orderer. Чтобы добавить новые организации / каналы в вашу работающую сеть, вы должны иметь доступ ко всем экземплярам сети и машине управляющей деплоем сети с использованием файла hosts_kafka.yml. https://github.com/Altoros/Ansible-Fabric-Starter/tree/v1.4.2
|
|
|
2.1.13 - Должна быть возможность разграничения полномочий участников сети |
|
|
Должна быть возможность разграничения полномочий участников сети |
Предоставлен способ или способы разграничения полномочий участников сети |
|
https://hyperledger-fabric.readthedocs.io/en/release-1.4/membership/membership.html Реализация MSP (Membership Service Provider) представляет собой набор папок, которые добавляются в конфигурацию сети и используются для определения организации как внутри (организации решают, кто их администраторы), так и снаружи (позволяя другим организациям подтверждать, что субъекты имеют полномочия делать то, что они пытаются сделать). Принимая во внимание, что Центры Сертификации (Certificate Authorities CA) генерируют аттестаты подлинности (цифровой сертификат, удостоверяющий личность), которые представляют идентификаторы, MSP содержит список разрешенных идентификаторов. MSP определяет, какие Root CA и Intermediate CA допущены к определению участников трастового домена, создавая список идентификаторов его участников, или определяя, какие СА уполномочены выдавать действительные идентификаторы для своих участников. Но возможности MSP выходят за рамки создания списков участников сети или участников канала. Именно MSP превращает идентификатор в роль, определяя конкретные привилегии и действия, которые субьект-участник может совершать на узле или канале. Когда пользователь зарегистрирован в Fabric CA, роль администратора, партнера, клиента, заказчика или участника должна быть связана с пользователем. Например, идентификаторы, зарегистрированные с ролью «пир» должны, естественно, передаваться пирам. Аналогичным образом, идентификаторы, зарегистрированные с ролью «администратор», должны передаваться администраторам организации. Локальные MSP определены для клиентов и для узлов (пиров и заказчиков). Локальные MSP определяют разрешения для узла (например, администраторы пиров, которые могут управлять узлом). Локальные MSP клиентов разрешают пользователю аутентифицировать себя в своих транзакциях в качестве участника канала (например, в транзакциях чейнкода), или как владельца определенной роли в системе, такой как администратор организации, например, в транзакциях конфигурации. У каждого узла должен быть определенный локальный MSP, поскольку он определяет, кто имеет административные права или права участия на этом уровне (администраторы-пиры не обязательно будут администраторами каналов, и наоборот). Это позволяет аутентифицировать сообщения участника вне контекста канала и определять разрешения для определенного узла (у кого есть возможность установить чейнкод на пир, например). Один или несколько узлов могут принадлежать организации. MSP определяет администраторов организации. И организация, администратор от организации, администратор узла и сам узел должны иметь одинаковый root of trust. Локальный MSP orderer также определяется в файловой системе узла и применяется только к этому узлу. Как и узлы пиров, orderer также принадлежат одной организации и поэтому имеют единый MSP для создания списка действующих лиц или узлов, которым он доверяет. Канальный MSP определят, кто имеет полномочия на канальном уровне. MSP канала определяет взаимосвязь между идентификаторами членов канала (которые сами являются MSP) и применением политики уровня канала. MSP канала содержат MSP организаций членов канала. |
|
|
2.1.14 - Взаимодействие с документами средствами платформы |
|
|
Составить сценарий с использованием документов Реализовать данный сценарий в рамках СБР |
Определить и настроить СБР, который предоставляет возможность использования документов. |
|
Возможна реализация взаимодействия с документами посредством ldap и samba. Платформа Hyperledger Fabric имеет возможность интеграции с ldap для реализации создания и управления пользователями через инструменты ldap вместо стандартных инструментов Fabric CA. Благодаря этому становится возможным управление доступом к общему хранилищу документов samba. Для интеграции samba с ldap можно воспользоваться docker контейнером https://hub.docker.com/r/andrespp/samba-ldap/dockerfile/ Для совместной работы samba и ldap необходимо предоставить образу конфигурационные файлы, ip адрес и порт ldap, а также соответствующим образом настроить ldap. |
|
|
2.1.15 - Управление сертификатами и подписями |
|
|
Предоставить описание механизма работы подписей, удостоверяющих центров и сертификатов |
Предоставлено описание механизма работы подписей, удостоверяющих центров и сертификатов. |
|
https://hyperledger-fabric.readthedocs.io/en/latest/membership/membership.html Центры сертификации выпускают идентификаторы, генерируя открытый и закрытый ключи, которые образуют пару ключей, которую можно использовать для подтверждения личности. Поскольку закрытый ключ никогда не может быть открыт для общего доступа, необходим механизм, который позволяет включить такое доказательство, в которое входит MSP. Например, одноранговый узел использует свой закрытый ключ для цифровой подписи или подтверждения транзакции. MSP в сервисе orderer содержит открытый ключ партнера, который затем используется для проверки правильности подписи, приложенной к транзакции. Закрытый ключ используется для создания подписи транзакции, которой может соответствовать только соответствующий открытый ключ, являющийся частью MSP. Таким образом, MSP - это механизм, который позволяет доверять и распознавать этот идентификатор остальной части сети, даже не раскрывая приватный ключ участника.
https://hyperledger-fabric.readthedocs.io/en/release-1.4/identity/identity.html Цифровые Сертификаты Цифровой сертификат - это документ, который содержит набор атрибутов владельца сертификата. Наиболее распространенный тип сертификата - стандарт X.509, он позволяет кодировать идентификационные данные участника в своей структуре. Аутентификация, открытые ключи и закрытые ключи Аутентификация и целостность сообщений являются важными концепциями в сфере защиты связи. Аутентификация требует, чтобы стороны, обменивающиеся сообщениями, были уверены в подлинности участника, создавшего конкретное сообщение. Понятие «целостность сообщения» подразумевает неизменяемость сообщения во время его передачи. Традиционные механизмы аутентификации полагаются на цифровые подписи, которые, как следует из названия, позволяют стороне подписывать свои сообщения цифровой подписью. Они также предоставляют гарантии целостности подписанного сообщения. Технически говоря, механизмы цифровой подписи требуют, чтобы каждая сторона имела два криптографически связанных ключа: открытый ключ и закрытый ключ. Получатели сообщений с цифровой подписью могут проверить происхождение и целостность полученного сообщения, проверив, что присоединенная подпись действительна, воспользовавшись ключом от ожидаемого отправителя. Центры сертификации Субъект или узел может участвовать в сети блокчейн с помощью цифрового идентификатора, выданного ему центром, которому доверяет система. В наиболее распространенном случае цифровые идентификаторы (или просто идентификаторы) имеют форму криптографически подтвержденных цифровых сертификатов, которые соответствуют стандарту X.509 и выпускаются Центром Сертификации (ЦС). Центр сертификации выдает сертификаты различным субъектам. Эти сертификаты подписаны ЦС в цифровой форме и связывают субъекта с открытым ключом. В результате, если кто-то доверяет ЦС (и знает его открытый ключ), он может доверять тому, что конкретный субъект связан с открытым ключом, включенным в сертификат, и владеет включенными в него атрибутами. У ЦС также есть сертификат, который является публичным. Это позволяет потребителям идентификаторов, выданных данным ЦС, подтверждать их, проверяя, что сертификат мог быть сгенерирован только владельцем соответствующего закрытого ключа (т.е. ЦС). В контексте блокчейна каждому субъекту, который хочет взаимодействовать с сетью, нужен идентификатор. В этом ключе можно сказать, что один или несколько ЦС могут использоваться для определения членов организации с цифровой точки зрения. Именно ЦС обеспечивает базис для субъектов организации, создавая поддающиеся проверке цифровые идентификаторы. Корневые центры сертификации, промежуточные центры сертификации и «цепочки доверия» ЦС бывают двух видов: корневые ЦС и промежуточные ЦС. Поскольку корневые ЦС (Symantec, Geotrust и т. д.) должны безопасно распространять сотни миллионов сертификатов среди пользователей Интернета, имеет смысл распространить этот процесс на так называемые промежуточные ЦС. Эти промежуточные ЦС имеют свои сертификаты, выданные корневым ЦС или другим промежуточным центром, что позволяет устанавливать «цепочку доверия» для любого сертификата, который выдается любым ЦС в цепочке. Возможность отслеживать сертификаты до корневого ЦС позволяет масштабировать функции ЦС и обеспечивать безопасность, позволяет организациям, использующим сертификаты, уверенно использовать Промежуточные ЦС, ограничивает уязвимость корневого ЦС, которая в случае компрометации может поставить под угрозу всю цепочку доверия. При компрометации промежуточного ЦС, это воздействие будет намного меньше. Цепочка доверия устанавливается между корневым ЦС и набором промежуточных ЦС, если выдающий сертификаты ЦС для каждого из этих промежуточных ЦС является либо самим корневым ЦС, либо имеет цепочку доверия к корневому ЦС. Промежуточные ЦС обеспечивают большую гибкость, когда дело доходит до выдачи сертификатов в нескольких организациях, и это очень полезно в распределенной блокчейн системе Fabric. Например, можно увидеть, что разные организации могут использовать разные корневые ЦС или один и тот же корневой ЦС с разными промежуточными ЦС - это зависит от потребностей сети. Fabric CA (ЦС) Поскольку ЦС настолько важны, Fabric предоставляет встроенный компонент ЦС, который позволяет создавать собственные ЦС для сети блокчейн. Этот компонент, известный как Fabric CA (ЦС), - это частный корневой ЦС, способный управлять цифровыми идентификаторами участников Fabric, предоставляемые им сертификаты соответствуют стандарту X.509. Поскольку Fabric ЦС - это пользовательский ЦС, ориентированный на потребности корневого ЦС в сети Fabric, он не способен предоставлять сертификаты SSL для общего / автоматического использования в браузерах (т. к. они считаются само подписанными). Тем не менее, поскольку для управления идентификаторами необходимо использовать некоторый ЦС (даже в тестовой среде), можно использовать Fabric ЦС для предоставления сертификатов и управления ими. Также возможно - и полностью уместно - использовать общедоступный / коммерческий корневой или промежуточный ЦС для обеспечения идентификации. Списки отозванных сертификатов Список отозванных сертификатов (CRL) не сложен для понимания - это список ссылок на сертификаты, отозванные по той или иной причине. Когда третья сторона хочет проверить идентификатор другой стороны, она сначала проверяет CRL выдающего ЦС для того, чтобы убедиться, что сертификат не был отозван. Верификатор не обязан проверять CRL, но если он этого не делает, он рискует принять скомпрометированный идентификатор. CRL используется для проверки того, что сертификат все еще действителен. Если злоумышленник пытается передать скомпрометированный цифровой сертификат проверяющей стороне, его необходимо сначала проверить по CRL выдавшего ЦС для того, чтобы убедиться, что он не указан как недействительный. Отметим, что отзываемый сертификат сильно отличается от сертификата с истекшим сроком действия. Аннулированные сертификаты не истекли - по всем остальным параметрам они являются полностью действительными сертификатами.
|
|
|
2.1.16 - Поддержка смарт-контрактов |
|
|
Составить синтетический бизнес-процесс Обозначить ключевые точки синтетического процесса и его артефакты Составить сценарий работы Реализовать синтетический бизнес-процесс в рамках СБР посредством смарт-контрактов |
Необходимо предоставить описание установки чейн-кода на узлы платформы. |
|
https://hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/smartcontract.html Поддержка смарт-контрактов Смарт-контракт определяет различные состояния бизнес-объекта и управляет процессами, которые перемещают объект между этими различными состояниями. Смарт-контракты важны, потому что они позволяют архитекторам и разработчикам смарт-контрактов определять ключевые бизнес-процессы и данные, которые совместно используются различными организациями, сотрудничающими в сети блокчейн. Одна и та же версия смарт-контракта должна использоваться всеми приложениями, подключенными к сети, чтобы они совместно выполняли одни и те же общие бизнес-процессы с одинаковыми данными. Разработка смарт контрактов поддерживается на golang, java, node, TypeScript, а также на любом из языков способных работать в средах выполнения Java Virtual Machine и Node.js. В Java и TypeScript аннотации или декораторы используются для предоставления информации о смарт-контракте и его структуре. Это обеспечивает более богатый опыт разработки - например, могут быть прикреплены информация об авторе или типы возвращаемых данных. В JavaScript должны соблюдаться условия, поэтому существуют ограничения относительно того, что может быть определено автоматически. На данный момент пример на golang разработчики платформы не ввели, но присутствует строчка “The sample will become available for Go as well” что означает это планируется добавить в будущем.
Инструкция по установке чейнкода
Для установки чейнкода при помощи cli необходимо на каждой машине ввести при помощи терминала две команды одна из которых устанавливает, а другая подтверждает установку. При этом код смартконтракта должен быть предварительно скопирован на каждую из машин в папку, которая прописана в volumes, docker compose файла для cli контейнера.
Для golang смартконтракта используется gopath вместо обычного пути и он так же описан в этом файле. Дополнительно для чейнкода на golang нужно предварительно собрать все зависимости в папку vendor при помощи инструмента govendor.
docker exec 'cli.org0.example.com' bash -c 'export CORE_PEER_ADDRESS=peer0.org0.example.com:7051 && peer chaincode install -n chaincode_common_name -v chaincode_version -p /opt/gopath/src/chaincode_common_name -l chaincode_lang
где - cli.org0.example.com название вашего контейнера с cli
docker exec cli.org0.example.com bash -c 'export CORE_PEER_ADDRESS=peer0.org0.example.com:7051 && peer chaincode instantiate -n chaincode_common_name -l chaincode_lang -v chaincode_version -c {"Args":["set","a","100"]} -o orderer0.example.com:7050 -C common_channel_name --tls --cafile /etc/hyperledger/artifacts/crypto-config/ordererOrganizations/example.com/orderers/ordererorderer0.example.com/tls/ca.crt collections_config_param collections_config_path'
где - cli.org0.example.com название вашего контейнера с cli
|
|
|
2.1.17 - Механизмы CI/CD |
|
|
Предоставить описание вариантов реализации постоянной интеграции и непрерывной доставки (как для компонентов, отвечающих за бизнес логику, так и для компонентов самой платформы) Проверить возможность использования корпоративных средств CI/CD, внедряемых в рамках создания корпоративной PaaS |
Ввиду сложности и большого количества вариантов развёртывания CI/CD, а также невозможности интеграции с корпоративной PaaS предлагается документально продемонстрировать возможности подобной интеграции. |
|
https://medium.com/@javaguirre/ci-cd-on-a-hyperledger-fabric-project-6f05f2b4ea5c В данной статье приведены описания CI/CD процессов с использованием Gitlab CI. Изложен опыт использования IBM Blockchain platform на примере @The Neon Project для развертывания и настройки сети Hyperledger Fabric. https://medium.com/ibm-garage/how-achieve-ci-cd-using-a-toolchain-template-for-hyperledger-fabric-bccca736d854 В данной статье описан вариант реализации CI/CD с помощью шаблона Toolchain для Hyperledger Fabric. |
|
|
2.1.18 - Логирование |
|
|
Реализовать протоколирование событий одного из сценариев работы в рамках СБР Предоставить возможность платформы протоколирования событий уровня платформы |
Необходимо предоставить пример журнала системных событий и несколько скриншотов для демонстрации в отчёте. |
|
Для получения логов работы HLF можно воспользоваться docker logs по контейнерам с компонентами платформы.
Сделаем просмотр логов с помощью docker logs container ID
Дополнительно можно получать логи СБР как с помощью стандартных средств операционной системы (/var/log/*) так и при помощи docker logs или других автоматизированных утилит для отправки в SIEM или Elastic.
|
|
|
2.3.1.1.1 - ИБ1. Для идентификации пользователей при доступе каждому пользователю должен быть назначен уникальный персональный идентификатор |
|
|
Составить физическую модель данных пользователей учитывая наличие уникального идентификатора Реализовать данную физическую модель данных в рамках СБР Заполнить созданное хранилище тестовыми данными Составить сценарий с использованием уникальных идентификаторов пользователей Реализовать данный сценарий в рамках СБР |
Предоставить возможность обеспечения идентификации пользователя в СБР, предоставить возможность назначения пользователю уникального персонального идентификатора.
|
|
При использовании ldap в качестве базы данных пользователей CA используются уникальные идентификаторы.
Для создания пользователя необходимо сначала создать группу, путем нажатия create child entry.
Выбрать Generic: Posx Group
Задать собственное название группы и создать её.
Подтвердить создание
Успешно созданная группа.
Теперь необходимо создать самого пользователя снова выбрав раздел create child entry.
Далее следует выбрать Generic: user account.
На следующем скриншоте представлено заполнение формы тестовыми данными. Стоит учитывать Fabric CA некорректно работает с пробелами в common name.
По окончании заполнения необходимо нажать create object.
Для внесения соответствующих изменений необходимо подтвердить действие нажав commit.
На скриншоте ниже представлен пример успешного завершения операции.
Теперь учётная запись пользователя активна и готова к работе. Далее представлена попытка создать пользователя с другими данными, но при этом оставив идентификатор первой учетной записи.
Произведено изменение в поле name и password остальное заполнено в соответствии с аккаунтом первого пользователя (предполагается, что они имеют одинаковую фамилию).
После заполнения необходимо подтвердить действие.
Как можно увидеть на следующем скриншоте идентификатор уже был использован, соответственно данное поле является уникальным для всех пользователей.
Далее представлены попытка подключения тестового пользователя через cli Fabric CA посредством уникального идентификатора и пароля.
На скриншоте ниже можно увидеть лог успешного завершения команды.
Далее представлена попытка несуществующего пользователя подключиться к Fabric CA закончившаяся неудачей.
|
|
|
2.3.1.1.2 - ИБ1-1. Должна поддерживаться взаимная идентификация узлов взаимодействия при подключении к платформе |
|
|
Составить сценарий с использованием идентификации узлов при подключении к платформе Реализовать данный сценарий в рамках СБР |
Предоставить описание возможности подключения к платформе узлов посредством процедуры идентификации. |
|
Для идентификации узлов и остальных компонентов сети hyperladger fabric используются сертификаты предоставляемые центрами сертификации.
Для прохождения процедуры идентификации можно воспользоваться скриптом предназначенным для службы заказа kafka, который добавит новую организацию с одним пиром к существующей сети.
Настройка новой машины для организации. Необходимо изменить файл hosts_new_org.yml следующим образом: Установить переменную newcomers для всех узлов. Необходимо добавить название новой организаций в существующие каналы (проверьте соответствуют ли названия каналов и организаций названиям уже существующим в вашей сети). Определить новые каналы в переменной new_channels если необходимо добавить канал. Увеличьте количество служб заказа в соответствии с новым размером вашей сети в переменной orderer_count. Отредактировать все новые организации с флагами peer, orderer и newcomer. Установить все зависимости на новой машине командой: ansible-playbook install-dependencies.yml -i hosts_new_org.yml Запустить развертывание в среде тестирования с помощью команды ansible-playbook add-new-org.yml -i hosts_new_org.yml
Во время исполнения скрипта происходит следующее:
raw: 'docker-compose exec "cli.{{ org }}.{{ domain }}" bash -c "export CORE_PEER_ADDRESS=peer0.{{ org }}.{{ domain }}:7051 && peer channel join -b {{ item.name }}.block"' она использует данные из переменных окружения пира для отправки запроса на присоединение к каналу с соответствующими сертификатами проходя тем самым процедуру идентификации. |
|
|
2.3.1.1.3 - ИБ2. Доступ пользователей должен осуществляться посредством парольной аутентификации |
|
|
Реализовать парольную аутентификацию в рамках СБР |
Предоставить возможность реализации аутентификации пользователей посредством ввода пароля. |
|
Реализация парольной аутентификации встроенная в Hyperledger Explorer реализуется средствами hlf, поэтому в качестве демонстрации доступа к СБР можно применить его. Hyperledger Explorer доступен на порте 8080 каждого узла, стандартные логин и пароль: admin, adminpw.
|
|
|
2.3.1.1.4 - ИБ3. Должна обеспечиваться защита обратной связи при вводе аутентификационной информации; ИБ30-4. Во время сеанса авторизации пользователя пароль должен быть либо скрыт маской либо не отображаться на экране |
|
|
Обеспечивается средствами ОС и Веб-сервера. Продемонстрировать скрывание пароля маской при использовании пользовательского интерфейса во время сеанса авторизации пользователя
|
Требуется предоставить документарное подтверждение в качестве использования HTTPS, а также подтверждение того, что система выдаёт «общие» ошибки при некорректной авторизации не раскрывая какая часть авторизации была некорректной (например, сообщений вида «такого пользователя не существует», или «для пользователя введён некорректный пароль», быть не должно, ошибки авторизации в обратной связи должны быть общего вида). Предоставлены снимки экрана, демонстрирующие скрытость пароля |
|
https://hyperledger-fabric.readthedocs.io/en/release-1.4/enable_tls.html https://hyperledger-fabric-ca.readthedocs.io/en/release-1.4/users-guide.html В документации ЦС сказано, что при включении tls сервер ЦС переходит на использование https. Также существует возможность активировать tls для узлов сети и для служб заказа.
Дополнительно можно обеспечить доступ к приложению посредством веб-сервера, например на базе nginx прописав в конфигурационном файле директиву auth_basic, таким образом будет обеспечиваться парольная защита на доступ к приложению. При переходе на определенный адрес и порт будет показано окно ввода логина пароля. Данная пара логин и пароль задается с помощью sudo htpasswd /etc/nginx/conf.d/.htpasswd user , и будет предложено ввести пароль для пользователя user.
|
|
|
2.3.1.1.5 - ИБ4. Локальная парольная политика должна удовлетворять требованиям |
|
|
В рамках СБР либо реализовать поддержку, либо продемонстрировать поддержку платформой следующих политик безопасности аутентификации:
возможность самостоятельной смены пароля |
Предоставить описание возможности реализации парольных политик безопасности аутентификации. |
|
Модуль ppolicy предоставляет возможности расширенного управления паролями, применяемые к попыткам подключения к OpenLDAP не от имени rootdn. Стандартное наложение ppolicy предоставляет следующие контролируемые пользователем возможности:
Подробная инструкция по настройке и добавлению политик паролей: https://tylersguides.com/guides/openldap-password-policy-overlay/ |
|
|
- 2.3.1.1.6 - ИБ5. Централизованное для каждого узла управление учетными записями пользователей должно осуществляться путем применения возможностей платформы |
|
|
Составить сценарий изменения учётных записей пользователя Реализовать данный сценарий посредством возможностей платформы в рамках СБР |
Предоставить возможность управления учетными записями пользователя посредством СБР. |
|
Описание. |
|
|
2.3.1.1.7 - ИБ6. Возможность интеграции с существующей системой управления идентификационными данными |
|
|
Составить сценарий интеграции с какой-либо существующей системой управления идентификационными данными Реализовать данный сценарий в рамках СБР |
Предоставить возможность интеграции с системой управления идентификационными данными (Keycloak) посредством Rest API. |
|
У Keyclock есть API https://www.keycloak.org/docs-api/9.0/rest-api/index.html Для осуществления интеграции необходимо реализовать оффчейн приложение через Fabric SDK. |
|
|
- 2.3.1.1.8 - ИБ7. Авторизация пользователей на доступ должна производиться только после прохождения процедур идентификации и аутентификации |
|
|
Составить физическую модель данных ролей пользователей Расширить физическую модель данных пользователей для поддержки ролевой модели Создать две роли Назначить двум пользователям по одной из этих ролей Создать пользователя без ролей Составить сценарий, при котором после аутентификации проверяется роль пользователя, а также осуществляется проверка при совершении какого-либо действия. Реализовать данный сценарий в рамках СБР |
Предоставить возможность проверки авторизации пользователя в СБР на основе ролей. |
|
Описание.
|
|
|
2.3.1.1.9 - ИБ8. Доступ пользователей должен осуществляться посредством аутентификации по сертификату пользователя и паролю |
|
|
Составить сценарий предоставления пользователю доступа по сертификату и паролю Реализовать данный сценарий в рамках СБР |
Показать возможность многофакторной авторизации. Например, авторизоваться с помощью сертификата, а потом дополнительно ввести логин и пароль.
|
|
Реализация двух факторной аутентификации осуществляется путем разработки оффчейн приложения через SDK. В качестве примера реализации 2fa: https://medium.com/@lichunshen84/build-a-blockchain-poc-application-using-hyperledger-fabric-5a32687072b7 |
|
|
2.3.1.2.1 - ИБ9. Должна использоваться система ролевого управления доступом для управления правами доступа пользователей |
|
|
Составить физическую модель данных прав доступа пользователей Расширить физическую модель данных ролей пользователей для поддержки прав доступа Составить два сценария использования (простых процесса) Создать два права на использование этих сценариев Назначить двум пользователям соответственно права на использование данных действий посредством ролевой модели Реализовать два сценария в рамках СБР |
Показать возможность, что только авторизованные пользователи с соответствующими правами могут выполнять реализованные процессы.
|
|
Взаимодействие пользователей с сетью блокчейн может разграничиваться при помощи нескольких средств.
При помощи политик: https://hyperledger-fabric.readthedocs.io/en/release-1.4/policies.html
При помощи MSP: https://hyperledger-fabric.readthedocs.io/en/release-1.4/membership/membership.html
И на стороне офчейн приложений регулироваться в зависимости от того, какой уровень доступа нужен пользователю для осуществления бизнес процессов. Описывать права доступа на основе груп можно при помощи централизованного хранилища профилей пользователей ldap. https://hyperledger-fabric-ca.readthedocs.io/en/release-1.4/users-guide.html
|
|
|
2.3.1.2.2 - ИБ9-1. Учётные записи использующиеся в процессе работы платформы должны быть персонифицированы |
|
|
Расширить физическую модель данных пользователей персональными данными (отдельная сущность) Реализовать данное расширение в рамках СБР Составить сценарий использования персонифицированных учётных записей Реализовать данный сценарий в рамках СБР |
Показать возможность, что учетные записи в СБР могут быть персонифицированы. |
|
При помощи phpldapadmin можно расширять учётные записи пользователей добавляя дополнительную информацию. Далее продемонстрированы создание пользователя и расширение данных путём добавления почты.
Создание пользователя.
Подтверждение создания пользователя.
Успешное завершение операции создания пользователя.
Добавление нового атрибута.
Выбор мэйла в качестве атрибута.
Подтверждение добавления атрибута.
Успешное завершение операции. |
|
|
2.3.1.2.3 - ИБ9-2. Механизмы управления доступом должны быть реализованы как на уровне UI, так и при обращении к API |
|
|
Механизм управления доступом – возможность изменения прав доступа и ролей пользователей Реализовать механизм управления доступом посредством UI (или Web, или local) в рамках СБР Реализовать механизм управления доступом посредством API в рамках СБР |
Показать возможность, что механизмы управления доступом в СБР могут быть реализованы посредством UI и API. |
|
Для регистрации нового пользователя в Fabric CA предусмотрен интерфейс командной строки. https://hyperledger-fabric-ca.readthedocs.io/en/release-1.4/users-guide.html#registering-a-new-identity Пример команды: export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/admin fabric-ca-client register --id.name admin2 --id.affiliation org1.department1 --id.attrs 'hf.Revoker=true,admin=true:ecert'
Также зарегистрировать пользователя можно при помощи Rest API: https://openblockchain.readthedocs.io/en/latest/API/CoreAPI/#rest-api Данное Api так же используется всеми поддерживаемыми платформой sdk.
При использовании ldap в качестве базы данных пользователей Fabric CA появляется возможность использования готового UI для регистрации пользователя в ldap. В качестве такого UI предоставлены скриншоты phpldapadmin.
|
|
|
2.3.1.2.4 - ИБ10. Наличие возможности определения уровня грануляции ролевой модели |
|
|
В рамках СБР реализовать грануляцию ролевой модели |
Данный пункт является ограничением HLF. Грануляцию ролевой модели можно реализовать посредством SDK. Необходимо представить теоретическое подтверждение из официальной документации факт возможности реализации в СБР. |
|
Грануляцию ролевой модели можно реализовать при помощи политик. Политики в hlf это набор правил устанавливающих разграничения на взаимодействие элементов сети. Например описание ролей сети в виде политики. message MSPRole { string msp_identifier = 1;
enum MSPRoleType { MEMBER = 0; // Represents an MSP Member ADMIN = 1; // Represents an MSP Admin CLIENT = 2; // Represents an MSP Client PEER = 3; // Represents an MSP Peer }
MSPRoleType role = 2; } MEMBER соответствует любому сертификату, выданному MSP. ADMIN соответствует сертификатам, перечисленным как admin в определении MSP. PEER соответствует служебным сертификатам.
Так выглядят политики по умолчанию, с их помощью можно настроить различные уровни разграничения доступа используя относительно простые правила такие как ANY или OR . /Channel/Readers : ImplicitMetaPolicy for ANY of /Channel/*/Readers /Channel/Writers : ImplicitMetaPolicy for ANY of /Channel/*/Writers /Channel/Admins : ImplicitMetaPolicy for MAJORITY of /Channel/*/Admins
/Channel/Application/Readers : ImplicitMetaPolicy for ANY of /Channel/Application/*/Readers /Channel/Application/Writers : ImplicitMetaPolicy for ANY of /Channel/Application/*/Writers /Channel/Application/Admins : ImplicitMetaPolicy for MAJORITY of /Channel/Application/*/Admins
/Channel/Orderer/Readers : ImplicitMetaPolicy for ANY of /Channel/Orderer/*/Readers /Channel/Orderer/Writers : ImplicitMetaPolicy for ANY of /Channel/Orderer/*/Writers /Channel/Orderer/Admins : ImplicitMetaPolicy for MAJORITY of /Channel/Orderer/*/Admins
# Here * represents either Orderer, or Application, and this is repeated for each org /Channel/*/Org/Readers : SignaturePolicy for 1 of MSP Principal Org Member /Channel/*/Org/Writers : SignaturePolicy for 1 of MSP Principal Org Member /Channel/*/Org/Admins : SignaturePolicy for 1 of MSP Principal Org Admin https://hyperledger-fabric.readthedocs.io/en/release-1.4/policies.html
|
|
|
2.3.1.2.5 - ИБ11. Наличие возможности управления ролями на основе групп |
|
|
Составить физическую модель данных групп пользователей Расширить физическую модель данных пользователей для поддержки групп Расширить физическую модель данных прав доступа для поддержки групп Составить два сценария использования (простых процесса) Создать два права на использование этих сценариев Создать две группы пользователей Назначить двум группам пользователей соответственно права на использование данных действий посредством ролевой модели Добавить по одному пользователю в каждую из групп Реализовать два сценария в рамках СБР
|
Только авторизованные пользователи, состоящие в соответствующих группах с соответствующими правами, могут выполнять реализованные процессы. Описать возможность привязки к группам MS AD.
|
|
В hyperledger fabric присутствуют несколько атрибутов предоставляющих разграничение контроля доступа.
При включении ldap блокируется возможность регистрации пользователей средствами fabric ca, поэтому использование атрибутов связанных с регистрацией не приведёт к желаемому результату. Остальные атрибуты можно присвоить пользователям добавляя в конфигурации к следующим строкам: converters: - name: hf.GenCRL value: attr("uid") =~ "user*" Например:
converters: - name: hf.GenCRL value: attr("uid") =~ "user*" - name: hf.AffiliationMgr value: attr("uid") =~ "mgr*"
Так же это можно использовать при распределении прав между группами пользователей. |
|
|
2.3.1.2.6 - ИБ12. Поддержка возможности наследования прав доступа |
|
|
Реализовать в рамках СБР возможность наследования прав доступа для групп пользователей |
Данный пункт является ограничением HLF. Наследование прав доступа для групп пользователей можно реализовать посредством SDK. Необходимо представить теоретическое подтверждение из официальной документации факт возможности реализации в СБР. |
|
При помощи офчейн приложения можно разграничить доступ пользователей к тем или иным бизнес процессам.
Примеры библиотек на поддерживаемых платформой языках, предоставляющих функционал достаточный для настройки наследования доступа. Nodejs https://github.com/stalniy/casl Golang https://github.com/casbin/casbin Java https://github.com/casbin/jcasbin Python https://github.com/casbin/pycasbin |
|
|
2.3.1.2.7 - ИБ13. Подсистема разграничения доступа должна позволять предоставлять права доступа в минимально необходимом объеме |
|
|
Представить наличие у СБР возможности устанавливать права в минимально необходимом объёме |
Данный пункт является ограничением HLF. Устанавливать права можно реализовать посредством SDK. Необходимо представить теоретическое подтверждение из официальной документации факт возможности реализации в СБР. |
|
При помощи офчейн приложения можно разграничить доступ пользователей таким образом, что права будут предоставлены в минимально необходимом объёме.
Примеры библиотек на поддерживаемых платформой языках, предоставляющих функционал достаточный для настройки наследования доступа. Nodejs https://github.com/stalniy/casl Golang https://github.com/casbin/casbin Java https://github.com/casbin/jcasbin Python https://github.com/casbin/pycasbin |
|
|
2.3.1.2.8 - ИБ14. Должен быть ограничен доступ к интерфейсу администрирования, конфигурационным и временным файлам |
|
|
Предоставить возможности платформы разграничивать доступ к интерфейсу администрирования, конфигурационными и временными файлами |
Предоставлена информация о возможностях платформы разграничивать доступ к интерфейсу администрирования, конфигурационными и временными файлами |
|
https://hyperledger-fabric.readthedocs.io/en/release-1.4/access_control.html Список Управления Доступом
Fabric использует списки управления доступом (ACLs) для управления доступом к ресурсам, сопоставляя установку - которая определяет правило, что оценивается как истинное или ложное, с учетом набора идентификаторов - с ресурсом. Fabric содержит несколько списков ACL по умолчанию.
Значения по умолчанию для управления доступом существуют внутри configtx.yaml, файла, который configtxgen использует для создания конфигураций канала.
Управление доступом может быть обновлено одним из двух способов, либо путем редактирования самого configtx.yaml, который будет использоваться при создании новых конфигураций канала, либо путем обновления управления доступом в конфигурации существующего канала.
Списки ACL форматируются в виде пары ключ-значение, состоящей из названия функции ресурса, сопровождающееся строкой. Две выборки из этого примера:
# Установка ACL для вызова чейнкодов на пире peer/Propose: /Channel/Application/Writers
# Установка ACL для отправки событий блока event/Block: /Channel/Application/Readers
Эти списки ACL определяют, что доступ к ресурсам peer/Propose и event/Block ограничен идентификаторами, удовлетворяющими политике, определенной на каноническом пути /Channel/Application/Writers и /Channel/Application/Readers, соответственно.
Обновление ACL по умолчанию в configtx.yaml
В тех случаях, когда при инициализации сети потребуется переопределить значения по умолчанию списка ACL или изменить списки ACL перед инициализацией канала, лучше всего обновить файл configtx.yaml.
Допустим, хотим изменить peer/Propose список ACL по умолчанию - который задает политику вызова чейнкодов на пире - из /Channel/Application/Writers в политику под названием MyPolicy.
Это делается путем добавления политики под названием MyPolicy (она может называться как угодно, но для этого примера назовем ее MyPolicy). Политика определяется в разделе Application.Policies внутри configtx.yaml и определяет правило для проверки возможности предоставления или запрета доступа пользователю. В этом примере создадим политику Signature, которая идентифицирует SampleOrg.admin.
Policies: &ApplicationDefaultPolicies Readers: Type: ImplicitMeta Rule: "AN Readers" Writers: Type: ImplicitMeta Rule: "ANY Writers" Admins: Type: ImplicitMeta Rule: "MAJORITY Admins" MyPolicy: Type: Signature Rule: "OR('SampleOrg.admin')"
Затем изменим Application: ACLs раздел в configtx.yaml, чтобы сменить peer/Propose с:
peer/Propose: /Channel/Application/Writers
На:
peer/Propose: /Channel/Application/MyPolicy
После того как эти поля изменены в configtx.yaml, инструмент configtxgen будет использовать политики и список ACL, определенные при создании транзакции канала. После подписи и подачи одним из администраторов участников консорциума создается новый канал с определенными списками ACL и политиками.
Как только MyPolicy был загружен в конфигурацию канала, на него также можно ссылаться чтобы переопределить другие значения по умолчанию списка ACL. Например:
SampleSingleMSPChannel: Consortium: SampleConsortium Application: <<: *ApplicationDefaults ACLs: <<: *ACLsDefault event/Block: /Channel/Application/MyPolicy
Это ограничит возможность подписки на заблокированные события SampleOrg.admin.
Если уже созданы каналы, которые хотят использовать этот ACL, им нужно обновить конфигурации каналов по одному, используя следующий поток: Updating ACL defaults in the channel config
Если уже созданы каналы, которые хотят использовать MyPolicy для ограничения доступа к peer/Propose - или если они хотят создавать списки ACL, о которых не должны знать другие каналы, - им придется обновлять конфигурации каналов по одному через config update транзакции.
После извлечения, перевода и удаления в блоке конфигурации его метаданных нужно отредактировать конфигурацию, добавив MyPolicy под Application: политики, где уже есть установки Admins, Writers, и Readers.
"MyPolicy": { "mod_policy": "Admins", "policy": { "type": 1, "value": { "identities": [ { "principal": { "msp_identifier": "SampleOrg", "role": "ADMIN" }, "principal_classification": "ROLE" } ], "rule": { "n_out_of": { "n": 1, "rul": [ { "signedby": 0 } ] } }, "version": 0 } }, "version": "0" },
Необходимо обратить внимание, в частности, на msp_identifer и его роль.
После чего в разделе списков ACL в config изменить peer/Propose ACL c:
"peer/Propose": { "policy_ref": "/Channel/Application/Writers"
На:
"peer/Propose": { "policy_ref": "/Channel/Application/MyPolicy"
Если в конфигурации канала не определены списки ACL, нужно добавить всю структуру ACL.
Как только конфигурация обновлена, ее нужно утвердить обычным процессом обновления канала.
Отвечающий требованиям список ACL, с требованием доступа к нескольким ресурсам.
Если участник делает запрос, который вызывает несколько системных чейнкодов, все списки ACL для этих системных чейнкодов должны отвечать требованиям.
Например, peer/Propose относится к любому запросу заявки на канале. Если конкретная заявка требует доступа к двум чейнкодам системы, для которых требуется идентификатор типа Writers, и одному чейнкоду системы, который требует идентификатор типа MyPolicy, тогда участник, отправляющий заявку, должен иметь идентификатор, который оценивается как «true» для Writers и MyPolicy одновременно.
В конфигурации по умолчанию установка подписи Writers с правилом SampleOrg.member. Другими словами, «любой член моей организации». MyPolicy, о котором говорилось выше, имеет правило SampleOrg.admin или «любой админ моей организации». Чтобы отвечать требованию этих списков ACL, участник должен быть и администратором, и членом SampleOrg. По умолчанию все администраторы являются участниками (хотя не все администраторы являются участниками), но эти установки можно перезаписать так, как необходимо. В результате важно отслеживать эти установки для обеспечения того, что списки ACL для запросов пиров отвечают требованиям (если не требуется обратного).
|
|
|
2.3.1.2.9 - ИБ15. Анонимное подключение должно быть запрещено |
|
|
Предоставить доказательство невозможности анонимного подключения к узлу блокчейн сети |
Предоставлен либо журнал событий платформы с отказом анонимного подключения к узлу, либо иное доказательство |
|
https://hyperledger-fabric.readthedocs.io/en/release-1.4/whatis.html Различия частной и публичной сетей блокчейн. В публичной сети блокчейн может участвовать практически каждый, и каждый участник является анонимным. В таком контексте не может быть никакого доверия, кроме того, что состояние цепочки блоков до определенной глубины является неизменным. Чтобы уменьшить это отсутствие доверия, в публичной сети блокчейн обычно используется собственная «mined» криптовалюта или пошлина за транзакции, чтобы обеспечить экономический стимул для компенсации чрезвычайных затрат на участие в форме отказоустойчивых byzantine fault tolerant консенсуса, основанного на «доказательстве работы» - “proof of work” (PoW) Разрешенные блокчейны, с другой стороны, управляют блокчейном с множеством известных, идентифицированных и часто проверяемых участников, работающих в рамках модели управления, которая обеспечивает определенную степень доверия. Разрешенный блокчейн обеспечивает способ защитить взаимодействия между группой объектов, которые имеют общую цель, но могут не полностью доверять друг другу. Опираясь на идентификаторы участников, разрешенный блокчейн может использовать более традиционные отказоустойчивые crash fault tolerant (CFT) или byzantine fault tolerant (BFT) консенсус протоколы, которые не требуют дорогостоящего майнинга. Кроме того, в таком разрешенном контексте снижается риск того, что участник преднамеренно введет вредоносный код с помощью смарт-контракта. Во-первых, участники известны друг другу, и все действия, будь то отправка транзакций приложения, изменение конфигурации сети или развертывание смарт-контракта, записываются в блокчейн в соответствии с политикой одобрения, которая была установлена для сети и соответствующего типа транзакции. В отличие от полной анонимности, виновная сторона может быть легко идентифицирована и инцидент обработан в соответствии с условиями модели управления. |
|
|
2.3.1.2.10 - ИБ16. Должен обеспечиваться запрет действий пользователей до прохождения процедуры идентификации и аутентификации |
|
|
Реализовать запрет действий пользователей до прохождения процедуры идентификации и аутентификации в рамках СБР |
Пользователям, не прошедшим процедуру идентификации и аутентификации, запрещено совершать в СБР какие-либо действия. |
|
На примере СБР Hyperledger Explorer если пользователь не прошел процедуру идентификации и аутентификации ему запрещается осуществлять просмотр состояния блокчейн сети. Для настройки данной функции необходимо предварительно включить enabel_autentication = true
|
|
|
2.3.1.2.11 - ИБ17. Должно обеспечиваться разграничение доступа между компонентами |
|
|
Необходимо разделить доступ к компонентам платформы (системами метрического анализа, логирования, администрирования и, непосредственно, функциональными компонентами платформы) и СБР между различными пользователями (как системными, так и пользователями платформы) |
Предоставлен отчёт о том, что только авторизованные пользователи могут иметь доступ к компонентам платформы и СБР
|
|
Разграничение прав доступа к компонентам платформы достигается за счет изоляции в виде разграничения прав доступа, в виде запуска в контейнерах или отдельных виртуальных машинах, за счет использования apparmor/selinux. Разграничение прав доступа в СБР зависит от ее реализации. В классическом случае, аутентификация пользователя осуществляется за счет ввода логина и пароля, иногда дополнительно применяются сертификаты, за счет этого достигается идентификация пользователя и предоставляются соответствующие права в СБР. |
|
|
2.3.1.2.12 - ИБ18. Должно обеспечиваться ограничение неуспешных попыток входа |
|
|
Либо средствами платформы, либо в рамках реализации СБР реализовать ограничение неуспешных попыток входа или подключения |
Данный пункт является ограничением HLF. Ограничение неуспешных попыток входа или подключений можно реализовать посредством SDK. Необходимо представить теоретическое подтверждение из официальной документации факт возможности реализации в СБР. |
|
Процедура ограничения неуспешных попыток входа осуществляется со стороны оффчейн приложения. Со стороны HLF таких ограничений нет. |
|
|
2.3.1.2.13 - ИБ19. Должна обеспечиваться автоматическая блокировка сессии после установленного периода неактивности (бездействия), восстановление сессии должно осуществляться только после повторной идентификации и аутентификации пользователя |
|
|
Средствами платформы, либо в рамках СБР реализовать блокировку сессии при неактивности пользователя в течении конфигурируемого периода. |
После конфигурируемого периода неактивности пользователя сессия блокируется. Для восстановления сессии требуется повторная идентификация и аутентификация пользователя. |
|
В Hyperledger Explorer присутствует возможность конфигурации времени жизни сессии:
После настройки приложения и по истечению заданного периода сессии осуществляется редирект на страницу авторизации пользователя.
|
|
|
2.3.1.3.1 - ИБ20. Наличие механизмов фиксации фактов нарушения ИБ и других связанных с безопасностью событий |
|
|
Предоставить наличие механизмов фиксации фактов нарушения ИБ и других связанных с безопасностью событий |
Предоставлены механизмы фиксации фактов нарушения ИБ и других событий, связанных с безопасностью с описанием этих механизмов |
|
Для фиксации фактов нарушения ИБ можно собирать различные логи и осуществить интеграцию с SIEM системой Splunk.
Установку и запуск Splunk можно осуществить в Docker контейнере: docker run -p 8000:8000 -e "SPLUNK_PASSWORD=<password>" \ -e "SPLUNK_START_ARGS=--accept-license" \ -it splunk/splunk:latest Необходимо указать пароль и после завершения процесса установки на порту 8000 запуститься Splunk.
Путем использования расширений Splunk можно получать и анализировать различные события ИБ, которые связаны не только с мониторингом ОС, но и HLF.
Процесс добавления модуля HLF для Splunk показан в п.2.3.1.3.2
|
|
|
2.3.1.3.2 - ИБ21. Должен быть предусмотрен централизованный интерфейс для работы с журналами событий безопасности |
|
|
Предоставить возможность использования централизованного интерфейса для работы с журналами событий безопасности |
Предоставлена возможность использования централизованного интерфейса для работы с журналами событий безопасности либо в виде пошаговой инструкции доступа к событиям, либо в виде описания используемого ПО Необходимо показать наличие соответствующих журналов и описание технического средства. |
|
Для обеспечения централизованного мониторинга событий как ОС так и HLF можно воспользоваться добавлением модуля HLF Splunk. https://splunkbase.splunk.com/app/4605/
Предварительно зарегистрировавшись на сайте splunk.com предоставляется возможность скачать расширение. Чтобы установить данное расширение необходимо в интерфейсе Splunk его добавить.
После установки оно появится в основном меню.
Если необходимо собирать лог транзакций для дополнительного анализа, можно воспользоваться расширением Splunk Connector for HLF: https://splunkbase.splunk.com/app/4612/
|
|
|
2.3.1.3.3 - ИБ22. Подсистема регистрации и учета событий ИБ должна обеспечивать перечень событий |
|
|
В платформе либо в СБР необходимо реализовать поддержку протоколирования следующих событий: • регистрацию даты и времени входа/выхода, попытки входа пользователя; • регистрацию даты и времени запуска/остановки компонент; • регистрацию изменения полномочий пользователей; • регистрацию изменения настроек; • регистрацию действий администраторов; • регистрацию действий пользователей • регистрацию новых пользователей • отключение и восстановление работоспособности узлов контура блокчейн платформы • протоколирование перечня транзакций, не прошедших процедуру консенсуса • протоколирование как событий при использовании UI, так и обращений к API |
Показать, что платформа и СБР поддерживают протоколирование перечисленных событий.
|
|
https://hyperledger-fabric.readthedocs.io/en/release-1.4/logging-control.html В контейнерах сети осуществляется логирование различных событий, существует несколько способов получить доступ к логам.
https://docs.google.com/document/d/1Ua0mBAoYvjRbCltCR6SOWz1SuSPTyGd1hceCP87WvQM/edit?ts=5e97# Для мониторинга логов в разделе Commercial pepper tutorial документации использовался logspout tool собирающий логи со всех контейнеров в сети и выдающий их в один терминал.
https://github.com/splunk/fabric-logger Так же есть такое решение для предоставления логов через Rest API.
Ниже предоставлен пример логов службы заказа, полученный при помощи команды docker logs.
Как показано на скриншоте поддерживаются различные уровни логирования событий. Уровень логирования можно настроить при помощи файлов конфигурации. |
|
|
2.3.1.3.4 - ИБ23. Журналы регистрации и учета событий ИБ должны храниться в течение заданного периода времени |
|
|
Предоставить возможность ограничения хранения времени журнала событий средствами платформы либо в рамках СБР |
Предоставлена возможность ограничения хранения времени журнала событий средствами платформы либо в рамках СБР с описанием этой возможности |
|
Хранение логов заданный период времени можно осуществить за счет использования cron или logrotate. |
|
|
2.3.1.3.5 - ИБ24. При заполнении установленного процента объема памяти, выделенного для хранения журналов регистрации событий ИБ, должно выдаваться соответствующее предупреждение |
|
|
Реализовать либо средствами платформы, либо в рамках СБР механизм уведомления о заполнении установленного процента объёма памяти, выделенного для хранения журналов регистрации событий ИБ |
Платформа либо СБР направляют уведомление о наступлении события
|
|
В Splunk есть встроенная система нотификаций о наступлении минимального количества доступного места для записи (менее 10 процентов). Это можно увидеть в интерфейсе администрирования Splunk. В случае появления данного сообщения, можно или осуществить увеличение дискового пространства, перенос хранилища, или уменьшение 10 процентов в конфигурационных файлах. Дополнительно на узлах можно воспользоваться утилитой logrotate. Ротация логов может быть эффективным решением для передачи и хранения логов, осуществления оповещения по результатам ротации. С помощью logrotate можно получать логи как с компонентов HLF так и СБР предварительно настроив источник получения логов. |
|
|
2.3.1.3.6 - ИБ25. При заполнении установленного процента объема памяти, выделенного для хранения журналов регистрации событий ИБ, должна производиться перезапись событий |
|
|
Реализовать либо средствами платформы, либо в рамках СБР механизм уведомления о заполнении установленного процента объёма памяти, выделенного для хранения журналов регистрации событий ИБ |
Показать возможность, что платформа или СБР направляет уведомление о превышении лимитов объема памяти средствами cron и logrotate. |
|
За счет использования планировщика cron можно запускать скрипты по архивированию и отправки лог-файлов в заданный период времени. Logrotate предназначена для обеспечения ротации логов, имеет возможность гибкой конфигурации при наступлении какого события необходимо осуществлять ротацию логов и куда. |
|
|
2.3.1.3.7 - ИБ26. Журналы событий ИБ должны быть защищены от несанкционированного просмотра и внесения изменений |
|
|
Показать возможность изоляции журналов событий либо средствами платформы, либо в рамках СБР, либо средствами ОС |
Предоставлено описание возможности изоляции журнала событий от несанкционированного доступа либо средствами платформы, либо в рамках СБР, либо средствами ОС |
|
Обеспечение защиты от модификации логов HLF и ОС осуществляется на уровне контроля доступа к узлам только определенным пользователям и службам. Для безопасной передачи и хранения логов должна быть правильно настроена ротация логов и отправка (в зашифрованном канале) их в SIEM систему для хранения и анализа. |
|
|
2.3.1.3.8 - ИБ27. Системное время должно иметь возможность синхронизации с единым доверенным источником (поддержка NTP) |
|
|
Показать возможность платформы либо СБР либо ОС синхронизации системного времени с единым доверенным источником |
Предоставлено описание возможности синхронизации системного времени с единым доверенным источником |
|
Для синхронизации времени можно использовать стандартные демоны синхронизации времени ntpd и chronyd с доверенными серверами синхронизации времени, которые можно настроить в конфигурационных файлах указанных служб(демонов). |
|
|
2.3.1.3.9 - ИБ28. Должна поддерживаться интеграция с СМУИБ Arcsight (поддержка syslog) |
|
|
Интегрировать платформу либо СБР с СМУИБ Arcsight (поддержка syslog) |
Предоставлен отчёт о совместной работы платформы либо СБР с СМУИБ Arcsight (syslog). |
|
Описание как реализован контроль логов в HLF подробно описано в документации: https://hyperledger-fabric.readthedocs.io/en/release-1.4/logging-control.html Ошибки попадая на stderr можно захватывать и отправлять различными средствами, в том числе и syslog. |
|
|
2.3.1.4.1 - ИБ29. Должна поддерживаться совместная работа с антивирусным программным обеспечением |
|
|
Подготовить отчёт о возможности совместной работы платформы либо СБР с антивирусным ПО Подготовить отчёт о возможности интеграции с существующим антивирусным ПО, предпочтительно, производства РФ (напр. Kaspersky) |
Предоставлен отчёт о возможности совместной работы платформы либо СБР с антивирусным ПО Предоставлен отчёт о возможности интеграции с существующим антивирусным ПО, предпочтительно, производства РФ (напр. Kaspersky). |
|
Российские антивирусные решения Dr.Web и Kaspersky имеют возможность установки на операционные системы Linux. Они могут осуществлять проверку файловой системы и не оказывают значительного влияния на систему, не мешая таким образом функционированию приложений и HLF в целом. |
|
|
2.3.1.4.2 - ИБ30. Должна быть возможность интеграции с MaxPatrol |
|
|
Подготовить отчёт о возможности интеграции с MaxPatrol |
Необходимо документально продемонстрировать возможность интеграции с MaxPatrol. Также стоит упомянуть, какие из тестируемых ОС поддерживаются MaxPatroll. |
|
Maxpatrol является сетевым сканером уязвимостей, который может быть установлен в той же сети, что и сеть HLF. Maxpartol может осуществлять сканирование узлов на наличие уязвимостей в HLF и в решениях оффчейн приложений, которые взаимодействуют через сеть. Для сканирования Front-end части можно воспользоваться Acunetix, который может также быть установлен не на узлах HLF. |
|
|
2.3.1.4.3 - ИБ30-1. Контроль параметров конфигурации сканером защищенности MaxPatrol не должен оказывать существенного влияния на работоспособность |
|
|
Оценить степень влияния на работоспособность контроля параметров конфигурации сканером защищённости MaxPatrol в виде метрических показателей |
Необходимо документально продемонстрировать возможность интеграции с MaxPatrol. Также стоит упомянуть, какие из тестируемых ОС поддерживаются MaxPatroll. |
|
С учетом того, что Maxpatrol может быть запущен не на узлах HLF, проведение сканирования на наличие уязвимостей не должно оказывать значительного влияния на функционирование сети HLF. Maxpatrol имеет возможность сканировать операционные системы на базе Linux и Windows. |
|
|
2.3.1.4.4 - ИБ30-2. При невозможности интеграции с MaxPatrol должна быть дана оценка отсутствия оказания существенного влияния на работоспособность платформы |
|
|
Оценить степень влияния на работоспособность контроля параметров конфигурации в виде метрических показателей |
Необходимо документально продемонстрировать возможность интеграции с MaxPatrol. Также стоит упомянуть, какие из тестируемых ОС поддерживаются MaxPatroll. |
|
Присутствует возможность сканирования узлов HLF при помощи Maxpatrol. |
|
|
2.3.1.4.5 - ИБ30-3. Хранение паролей должно осуществляться в зашифрованном виде |
|
|
Подготовить отчёт о возможности хранения паролей использующихся в платформе или СБР в зашифрованном виде |
Предоставлен отчёт о возможности хранения паролей, использующихся в платформе или СБР в зашифрованном виде. Необходимо предоставить описание поддерживаемых алгоритмов хеширования. |
|
Хранение паролей осуществляется в зашифрованном виде.
|
|
|
- 2.3.1.4.7 - ИБ30-5. Должен поддерживаться механизм валидации подлинности участников информационного обмена, в том числе пользователей и систем использующихся для автоматизации процессов |
|
|
Подготовить отчёт о поддержке платформой либо СБР механизма валидации подлинности участников информационного обмена, в том числе пользователей и систем использующихся для автоматизации процессов |
Продемонстрировать возможность валидации (идентификации) посредством сертификатов (пример – датчики объективного контроля, служебное ПО, используемое для наполнения БР данными, ид). |
|
Описание. |
|
|
- 2.3.1.4.8 - ИБ31. Эксплуатационная документация должна включать информацию о необходимых для функционирования сетевых параметрах (порт, протокол) |
|
|
Предоставить ссылки на соответствующую документацию |
Предоставлены ссылки на включение в эксплуатационную документацию информации о необходимых для функционирования сетевых параметрах (порты, протоколы) |
|
Описание. https://hyperledger-fabric.readthedocs.io/en/release-1.4/gossip.html Протокол распространения данных Gossip
Hyperledger Fabric оптимизирует производительность, безопасность и масштабируемость сети с помощью цепочки блоков, разделяя рабочую нагрузку между одноранговыми узлами выполнения транзакций (одобрения и принятия) и узлами упорядочения транзакций. Такое разделение сетевых операций требует безопасного, надежного и масштабируемого протокола распространения данных для обеспечения целостности и согласованности данных. Чтобы соответствовать этим требованиям, Fabric реализует протокол распространения данных gossip.
Пиры используют gossip для широковещательной передачи данных о текущем состоянии ledger и о канале. Обмен сообщениями через протокол gossip является непрерывным, и каждый узел на канале постоянно получает текущие и согласованные данные о состоянии ledger из нескольких узлов. Каждое сообщение gossip подписывается, что позволяет легко идентифицировать “византийские” пиры, отправляющие фальшивые сообщения, и предотвращать их дальнейшее распространение . Пиры подвергшиеся задержкам, сетевым перебоям или по другим причинам, пропустившие блоки, будут в конечном итоге синхронизированы до текущего состояния ledger, связываясь с пирами, имеющими эти недостающие блоки.
https://openblockchain.readthedocs.io/en/latest/protocol-spec/ Gossip построен на HTTP/2.
https://hyperledger-fabric.readthedocs.io/en/release-1.4/enable_tls.html Для шифрованного обмена данными существует возможность настройки TLS сертификатов.
https://openblockchain.readthedocs.io/en/latest/Setup/Network-setup/ Порты, необходимые для работы компонентов сети блокчейн настраиваются при развертывании. |
|
|
- 2.3.1.4.9 - ИБ32. Все пароли по умолчанию для встроенных учетных записей должны иметь возможность замены, а встроенные учетные записи возможность блокировки |
|
|
Подготовить отчёт о возможности замены в платформе и СБР всех паролей по умолчанию Подготовить отчёт о возможности блокировки встроенных учётных записей Подготовить сценарий аварийного обновления сертификатов и прав доступа для локальных пользователей, узлов платформы и самих компонентов узлов платформы в случае компрометирования
|
Подготовить отчёт о возможности замены в платформе и СБР всех паролей по умолчанию. Подготовить отчёт о возможности блокировки встроенных учётных записей. Подготовить сценарий аварийного обновления сертификатов и прав доступа для локальных пользователей, узлов платформы и самих компонентов узлов платформы в случае компрометирования.
|
|
Описание.
|
|
|
2.3.1.4.10 - ИБ33. Настройки по умолчанию, которые могут быть использованы для несанкционированного доступа, должны иметь возможность замены |
|
|
Подготовить перечень настроек платформы и СБР по умолчанию, которые могут быть использованы для несанкционированного доступа, данный перечень должен содержать подтверждение или опровержение возможности замены данных настроек |
Подготовлен перечень настроек платформы и СБР по умолчанию, которые могут быть использованы для несанкционированного доступа. |
|
В конфигурации Fabric CA присутствует учетная запись администратора по умолчанию она имеет вид: identities: - name: admin pass: adminpw Она подлежит обязательной замене. https://hyperledger-fabric-ca.readthedocs.io/en/release-1.4/serverconfig.html
По умолчанию tls выключен, что является небезопасным. Протокол http является уязвимым к атакам “человек посередине” в отличие от https, что может привести к компрометации сети. Эту настройку необходимо активировать для всех компонентов сети блокчейн. https://hyperledger-fabric.readthedocs.io/en/release-1.4/enable_tls.html |
|
|
2.3.1.4.11 - ИБ34. Должна обеспечиваться своевременная установка пакетов обновлений, по мере их публикации разработчиками |
|
|
Провести анализ и подготовить отчёт об обеспечении своевременной установки пакетов обновлений, по мере их разработчиками, как для платформы, так и для СБР |
Подготовлен отчёт об обеспечении своевременной установки пакетов обновлений. |
|
Исходный код HLF публикуется на Github, следовательно для установки обновлений по мере их поступлений необходимо реализовать pipeline CI/CD или написать скрипт, который при появлении нового релиза осуществит получение новой версии и установит ее на соответствующие узлы. |
|
|
2.3.1.5.1 - ИБ35. Обеспечение контроля целостности на уровне программных компонент и файлов конфигураций |
|
|
Подготовить сценарии обеспечения контроля целостности на уровне программных компонент и файлов конфигураций. |
Подготовлены сценарии обеспечения контроля целостности на уровне программных компонент и файлов конфигураций. |
|
В базовой поставке (собранной из исходных кодов или в Docker-образах) нет возможности осуществления контроля ценности поставляемых компонент встроенными средствами. Для достижения цели контроля исполняемых файлов необходимо воспользоваться сторонними средствами контроля хэш-сумму, например Криптопро. |
|
|
2.3.1.5.2 - ИБ35-1. Обеспечение контроля целостности информации, содержащейся в блоках |
|
|
Подготовить отчёт о механизмах контроля целостности информации, содержащейся в блоках |
Требуется предоставить информацию о механизмах контроля целостности их официальной документации. |
|
Одноранговые узлы выполняют проверку версий для набора чтения транзакций, чтобы обеспечить целостность данных и защиту от таких угроз, как двойные расходы. Hyperledger Fabric имеет управление параллелизмом, посредством которого транзакции выполняются параллельно (индоссантами) для увеличения пропускной способности, и после фиксации (всеми одноранговыми узлами) каждая транзакция проверяется, чтобы убедиться, что никакая другая транзакция не изменила прочитанные данные. Другими словами, это гарантирует, что данные, которые были прочитаны во время выполнения чейн кода, не изменились со времени выполнения (подтверждения), и, следовательно, результаты выполнения все еще действительны и могут быть зафиксированы в базе данных состояния. Если прочитанные данные были изменены другой транзакцией, то транзакция в блоке помечается как недействительная и не применяется к базе данных состояний. Клиентское приложение получает предупреждение и может обработать ошибку или повторить попытку в зависимости от ситуации. https://hyperledger-fabric.readthedocs.io/en/release-1.4/ledger.html
|
|
|
2.3.1.6.1 - ИБ36. Должна иметься возможность реализации в отказоустойчивом исполнении |
|
|
Предоставить отчёт о возможности реализации платформы и СБР в отказоустойчивом исполнении |
Необходимо документально показать возможность отказоустойчивой реализации и возможность использования кластера. |
|
Платформа изначально проектировалась для работы в отказоустойчивом исполнении. Каждый компонент платформы поставляется в виде контейнеров. Отказоустойчивость предусмотрена и на уровне алгоритмов консенсуса основанных на Kafka и Raft. https://developer.ibm.com/technologies/blockchain/articles/blockchain-hyperledger-fabric-ordering-decentralization/ |
|
|
2.3.1.6.2 - ИБ36-1. Должна быть обеспечена высокая доступность с заданными параметрами доступности |
|
|
Необходимо определить значения недоступности системы за период использования (например, коэффициент технического использования) |
Необходимо пояснить, что данные параметры целесообразны в рамках БР и отсутствует возможность объективной оценки данных параметров в рамках платформы. |
|
Для обеспечения максимальной доступности СБР на базе блокчейн платформы HLF необходимо собирать статистические данные по различным метрикам. В рамках СБР отсутствует возможность объективного сбора и оценки статистических данных, но в перспективе использования они важны, в том числе для формирования SLA. |
|
|
2.3.1.6.3 - ИБ37. Эксплуатационной документацией должны быть определены параметры резервного копирования |
|
|
Эксплуатационная документация СБР должна определять параметры резервного копирования |
Эксплуатационная документация СБР содержит параметры резервного копирования. |
|
Блокчейн технология изначально предполагает резервное копирование в отказоустойчивом исполнения (репликация блоков), в случае, когда существует хоть одна нода. Порядок резервирования не представлен в официальной документации HLF, но для резервирования СБР можно использовать различные существующие средства в виде бекапов, в виде запуска в Kubernetes и других средств, которые предполагают процесс быстрого или бесшовного восстановления функционирования СБР в случае отказа одного из экземпляров СБР. |
|
|
2.3.1.7.1 - ИБ38. Должно обеспечиваться безопасное сетевое взаимодействие (возможность фильтрации) между компонентами |
|
|
Провести анализ и подготовить отчёт о возможности и средствах обеспечения безопасного сетевого взаимодействия между компонентами |
Подготовлен отчёт о возможности и средствах обеспечения безопасного сетевого взаимодействия между компонентами |
|
Передача данных между компонентами сети может осуществляться по протоколу https при включении TLS в конфигурационных файлах. Также существует возможность взаимной TLS аутентификации предполагающей, что и сервер и клиентское приложение должны подтвердить свою подлинность.
Одноранговый узел является и сервером TLS, и клиентом TLS. Сервером - когда другой одноранговый узел, приложение или CLI устанавливает соединение с ним, а клиентом - когда он устанавливает соединение с другим одноранговым узлом или заказчиком. Чтобы включить TLS на одноранговом узле, необходимо установить следующие свойства конфигурации однорангового узла: peer.tls.enabled = true p = полный путь к файлу, который содержит сертификат сервера TLS peer.tls.key.file = полный путь к файлу, который содержит закрытый ключ сервера TLS peer.tls.rootcert.file = полный путь к файлу, который содержит цепочку сертификатов центра сертификации (ЦС), выдавшего сертификат сервера TLS По умолчанию аутентификация клиента TLS отключена, если на одноранговом узле включен протокол TLS. Это означает, что одноранговый узел не будет проверять сертификат клиента (другого однорангового узла, приложения или CLI) во время процедуры TLS-hadshake. Чтобы включить аутентификацию клиента TLS на одноранговом узле, необходимо задать для свойства конфигурации peer.tls.clientAuthRequired равным true и установить для свойства peer.tls.clientRootCAs.files файл(ы) цепочки ЦС, который(е) содержи(а)т цепочку(и) сертификатов ЦС, которые выпустили сертификаты TLS для клиентов организации. https://hyperledger-fabric.readthedocs.io/en/release-1.4/enable_tls.html |
|
|
2.3.1.7.2 - ИБ39. Должно обеспечиваться безопасное сетевое взаимодействие (возможность фильтрации) с внешними системами |
|
|
Провести анализ и подготовить отчёт о средствах обеспечения безопасности сетевого взаимодействия с внешними системами |
Подготовлен отчёт о средствах обеспечения безопасности сетевого взаимодействия с внешними системами |
|
Обеспечение безопасности при взаимодействии с внешними информационными системами осуществляется путем настройки firewall и apparmor/selinux. |
|
|
2.3.1.7.3 - ИБ40. Ограничение возможности аутентификации на основе IP-адреса клиента |
|
|
Провести анализ и подготовить отчёт о механизме ограничения возможности аутентификации на основе IP адреса клиента |
Подготовлен отчёт о механизме ограничения возможности аутентификации на основе IP адреса клиента |
|
Для клиентского приложения предусмотрен механизм взаимной аутентификации с сервером на основе сертификатов. В этом случае клиентское приложение должно подтвердить свою подлинность помимо IP предоставив сертификат. По умолчанию проверка подлинности клиента TLS отключена, как в случае с пиром. Чтобы включить аутентификацию клиента TLS, необходимо установить следующие свойства конфигурации:
General.TLS.ClientAuthRequired = true General.TLS.ClientRootCAs = полный путь к файлу, который содержит цепочку сертификатов центра сертификации, выдавшего сертификат сервера TLS. https://hyperledger-fabric.readthedocs.io/en/release-1.4/enable_tls.html
|
|
|
2.3.1.7.4 - ИБ41. При организации доступа из сети Интернет должна поддерживаться возможность обработки информации в разных сегментах сети (разделения серверов на Front-End и Back-End) |
|
|
Провести анализ и подготовить отчёт о поддержке возможности обработки информации в разных сегментах сети при организации доступа из сети Интернет |
Подготовлен отчёт о поддержке возможности обработки информации в разных сегментах сети при организации доступа из сети Интернет |
|
При разработке бизнес-приложений на базе блокчейн платформы HLF представляется возможность реализации раздельной обработки данных (Front-End, Back-End) путем использования SDK. SDK представляет набор методов для взаимодействия с блокчейн платформой, используя их можно реализовать back-end приложение, а в дальнейшем и front-end, c точки зрения архитектуры представляется возможность разделения back-end и front-end на разные узлы, таким образом достигая балансировки и резервирования. |
|
|
2.3.1.7.5 - ИБ42. Отсутствие неотключаемых функций взаимодействия с сетью Интернет |
|
|
Провести анализ и подготовить отчёт о возможности отключать в платформе или СБР функции взаимодействия с сетью интернет |
Подготовлен отчёт о возможности отключать в платформе или СБР функции взаимодействия с сетью интернет |
|
В СБР и HLF нет явной возможности отключения взаимодействия через сеть интернет. Достижение взаимодействия только в локальной сети можно осуществить путем настройки локальных ip адресов (192.168.0.0, 172.16.0.0, 10.0.0.0) в конфигурационных файлах сети HLF, при этом настроив фаервол таким образом, чтобы сетевые пакеты из данных ip адресов не маршрутизировались в сеть интернет. |
|
|
- 2.3.1.8.1 - ИБ43. Пароли (ключи) должны храниться и передаваться в зашифрованном виде |
|
|
Подготовить отчёт о механизме передачи паролей и ключей. Отчёт должен содержать возможность передачи паролей и ключей в зашифрованном виде |
Подготовлен отчёт о механизме передачи паролей и ключей |
|
Описание. |
|
|
2.3.1.8.2 - ИБ43-1. Должна быть обеспечена возможность проверки электронной подписи/сертификата узла или пользователя |
|
|
Подготовить отчёт о механизме обеспечения проверки электронной подписи/сертификата |
Подготовить отчёт о механизме обеспечения проверки электронной подписи/сертификата |
|
Сертификаты проверяются центром сертификации на наличие их в списке отозванных сертификатов. Список отозванных сертификатов (CRL) - это список ссылок на сертификаты, отозванные по той или иной причине. Когда третья сторона хочет проверить идентификатор другой стороны, она сначала проверяет CRL выдающего ЦС для того, чтобы убедиться, что сертификат не был отозван. Верификатор не обязан проверять CRL, но если он этого не делает, он рискует принять скомпрометированный идентификатор. CRL используется для проверки того, что сертификат все еще действителен. Если злоумышленник пытается передать скомпрометированный цифровой сертификат проверяющей стороне, его необходимо сначала проверить по CRL выдавшего ЦС для того, чтобы убедиться, что он не указан как недействительный. Отметим, что отзываемый сертификат сильно отличается от сертификата с истекшим сроком действия. Аннулированные сертификаты не истекли - по всем остальным параметрам они являются полностью действительными сертификатами. |
|
|
- 2.3.1.8.3 - ИБ44. Возможность хранения технических реквизитов (конфигурационных файлов) в зашифрованном виде |
|
|
Подготовить отчёт о механизме хранения технических реквизитов в зашифрованном виде |
Необходимо показать, что пароли пользователей в HLF хранятся в зашифрованном виде, что при реализации БР возможно хранение паролей пользователей в зашифрованном виде, а также показать, что возможно использование зашифрованных образов Docker (или всей ОС) при работе БР либо платформы в целом. |
|
Описание. |
|
|
2.3.1.8.4 - ИБ45. Должно обеспечиваться шифрование канала связи на уровне доступа пользователя |
|
|
Подготовить отчёт о механизмах обеспечения шифрования канала связи на уровне доступа пользователей |
Подготовлен отчёт о механизмах обеспечения шифрования канала связи на уровне доступа пользователей |
|
Поскольку пользователи взаимодействуют с блокчейн сетью при помощи клиентских приложений для шифрования канала можно использовать протокол https применяя его к api серверам. На данный момент доступны sdk на языках и для каждого из них существуют библиотеки с поддержкой https: Golang https://echo.labstack.com/cookbook/auto-tls Java https://docs.oracle.com/javase/8/docs/jre/api/net/httpserver/spec/com/sun/net/httpserver/HttpsServer.html Python http://2.python-requests.org/en/v1.1.0/user/advanced/ Nodejs https://nodejs.org/api/https.html |
|
|
- 2.3.1.8.5 - ИБ46. Должно обеспечиваться шифрование канала связи при внутрисистемном взаимодействии компонент |
|
|
Подготовить отчёт о механизмах обеспечения шифрования каналов связи при внутрисистемном взаимодействии компонент |
Подготовлен отчёт о механизмах обеспечения шифрования каналов связи при внутрисистемном взаимодействии компонент |
|
Описание. |
|
|
2.3.1.8.6 - ИБ47. Возможность интеграции с существующей инфраструктурой открытых ключей. |
|
|
Провести анализ и подготовить отчёт о механизме интеграции с существующей инфраструктурой открытых ключей |
Подготовлен отчёт о механизме интеграции с существующей инфраструктурой открытых ключей |
|
Присутствует возможность использовать сторонний CA который может генерировать сертификаты ECDSA. https://hyperledger-fabric.readthedocs.io/en/release-1.4/getting_started.html#hyperledger-fabric-ca |
|
|
2.3.1.8.7 - ИБ48. Должно обеспечиваться хранение ключей шифрования на отчуждаемом носителе |
|
|
Подготовить отчёт о возможности хранения ключей шифрования на отчуждаемом носителе |
Подготовлен отчёт о возможности хранения ключей шифрования на отчуждаемом носителе |
|
Клиентские сертификаты и ключи могут храниться следующим образом: https://hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/wallet.html Четыре разных типа кошельков: File system, In-memory, Hardware Security Module (HSM) и CouchDB. FileSystem: Это наиболее распространенное место для хранения кошельков; файловые системы распространены, просты для понимания и могут быть установлены в сети. Это хороший выбор по умолчанию для кошельков. В данном случае их можно хранить на отчуждаемом носителе задав соответствующую директорию для хранения. In-memory: Кошелек в памяти приложения. Используется этот тип кошелька, когда приложение работает в ограниченной среде без доступа к файловой системе; как правило, веб-браузер. Стоит отметить, что данный тип кошелька нестабилен; идентификаторы будут потеряны после нормального завершения приложения или сбоя. В данном случае невозможно хранить их на съемном носителе. Hardware Security Module: Кошелек, хранящийся в HSM. Это сверхбезопасное защищенное от взлома устройство хранит цифровую идентификационную информацию, в частности закрытые ключи. HSM могут быть локально подключены к компьютеру или доступны по сети. Большинство HSM предоставляют возможность выполнять встроенное шифрование с помощью закрытых ключей, так что закрытый ключ никогда не покидает HSM. CouchDB: Кошелек, хранящийся в Couch DB. Это самая редкая форма хранения кошелька, но для тех пользователей, которые хотят использовать механизмы бэкапа и восстановления базы данных, кошельки CouchDB могут предоставить полезную опцию для упрощения аварийного восстановления. В данном случае бэкапы можно хранить на съемном носителе.
Для центров сертификации так же предусмотрена настройка хранилища ключей. https://hyperledger-fabric-ca.readthedocs.io/en/release-1.4/users-guide.html#configuring-an-hsm Настройка HSM По умолчанию, сервер и клиент Fabric CA хранят закрытые ключи в файле с кодировкой PEM (для данного файла можно задать), но они также могут быть настроены для хранения закрытых ключей в HSM (Hardware Security Module) c помощью PKCS11 APIs. Это поведение настраивается в разделе BCCSP (BlockChain Crypto Service Provider) файла конфигурации сервера или клиента. В настоящее время Fabric поддерживает только стандарт PKCS11 для связи с HSM. |
|
|
- 2.3.1.8.8 - ИБ49. Возможность генерации сертификата пользователя на пользовательском узле блокчейн сети |
|
|
Средствами платформы или в рамках СБР реализовать генерацию сертификата пользователя на узле блокчейн сети Подготовить отчёт о механизме генерации сертификата пользователя на узле блокчейн сети |
Показать возможность обращения через SDK к существующему CA с запросом выдачи сертификата. |
|
Описание. |
|
|
2.3.2.1 - ИБ201. Возможность интеграции с брокерами очередей |
|
|
Провести анализ и подготовить отчёт о возможности интеграции платформы с брокерами очередей Apache Kafka. |
Подготовлен отчёт о возможности интеграции платформы с брокерами очередей Apache Kafka. |
|
В HLF 1.4.2. есть возможность запуска в режиме kafka. Запустив этот режим при помощи автоматизированных скриптов кроме компонентов HLF дополнительно поднимается kafka и zookeeper.
Начиная с Fabric v1.0 введена поддержка службы заказа на основе Kafka, но многие пользователи могут посчитать дополнительные административные издержки управления кластером Kafka пугающими или нежелательными. Подобно консенсусу на основе Raft, Apache Kafka - это реализация CFT, в которой используется конфигурация узла «лидер и последователь». В случае, если узел лидера выходит из строя, один из последователей становится лидером, и порядок может продолжаться, обеспечивая отказоустойчивость, как и в случае с Raft. Кафка использует ZooKeeper для согласования управления транзакциями.
|
|
|
2.3.2.2 - ИБ206. Анализ возможности сегрегации доступа к компонентам платформы |
|
|
Провести анализ и подготовить отчёт о возможности сегрегации доступа к компонентам платформы посредством пользователей, групп и ролей, предоставляемых выбранной ОС |
Провести анализ и подготовить отчёт о возможности сегрегации доступа к компонентам платформы посредством пользователей, групп и ролей, предоставляемых выбранной ОС |
|
По умолчанию все компоненты HLF запускаются в docker контейнерах. Docker контейнеры имеет право запускать пользователь или root или который входит в группу docker. В таком случае, если пользователь имеет права на запуск контейнеров, сегрегацию прав на компоненты HLF можно осуществить путем docker-proxy, в случае сегрегации сети, и с помощью apparmor/selinux. |
|
|
2.3.2.3 - ИБ207. Возможность обезличивания персональных данных методом замены на идентификаторы |
|
|
Подготовить отчёт о механизмах обезличивания персональных данных методом замены на идентификаторы |
Подготовлен отчёт о механизмах обезличивания персональных данных методом замены на идентификаторы |
|
В HLF можно реализовывать различные оффчейн приложения при помощи sdk, в частности предоставляется возможность реализации обезличивания персональных данных методами замены на идентификаторы. В случае введения идентификаторов - группа идентифицирующих атрибутов заменяется абстрактным идентификатором, группа будет хранится в отдельной таблице, в том числе представляется возможность хранения в блокчейне. Дополнительно можно осуществлять изменение состава или семантики, в таком случае изменяется структура (количество, положение и размер полей) или изменяется значение идентифицирующих атрибутов. Декомпозиция позволяет разделять данные на множество частей, таким образом информация о связях может хранится в отдельных цепочках блокчейна. Перемешивание группы идентифицирующих атрибутов позволяет осуществлять запись в идентифицирующие атрибуты другого человека. Все это достигается путем реализации алгоритмов, как при помощи разработки оффчейн приложения, так и встроенными средствами fabric-ca. |
|
|
2.3.2.4 - ИБ208. Платформа должна обеспечивать изоляцию подключения к узлам и использование данных посредством PKI |
|
|
Подготовить отчёт о механизмах, предоставляемых платформой обеспечивающих изоляцию подключения к узлам и использованию данных посредством PKI |
Подготовлен отчёт о механизмах, предоставляемых платформой обеспечивающих изоляцию подключения к узлам и использованию данных посредством PKI. Ввиду сложности проверки данной гипотезы для бизнес решения предлагается доказать такую возможность документально.
|
|
Реализация MSP в Fabric по умолчанию использует сертификаты X.509 в качестве идентификаторов, применяя традиционную иерархическую модель инфраструктуры открытых ключей (PKI). https://hyperledger-fabric.readthedocs.io/en/release-1.4/identity/identity.html |
|
|
2.4.1 - Требования к каналам связи |
|
|
Подготовить отчёт по требования платформы к каналам связи |
Подготовлен отчёт по требования платформы к каналам связи |
|
В официальной документации нет описания минимального требования к каналам связи, ввиду этого можно посмотреть сетевую нагрузку с помощью iptraf:
|
|
|
2.4.2 - Требования к аппаратному обеспечению |
|
|
Подготовить отчёт по требованиям платформы к аппаратному обеспечению |
Подготовлен отчёт по требованиям платформы к аппаратному обеспечению |
|
В официальной документации нет описания минимальных технических требований для запуска HLF, в таком случае можно посмотреть какое количество ресурсов потребляет запущенная сеть HLF (4 узла) в минимальном, ненагруженном исполнении с помощью утилиты htop:
|
|
|
2.4.3 - Поддержка |
|
|
Подготовить отчёт с описанием обеспечения четырёх линий поддержки пользователей |
Подготовлен отчёт с описанием обеспечения четырёх линий поддержки пользователей |
|
На первой линии поддержки пользователей осуществляются работы по решению проблем связанных с работой конечного приложения, и которые могут быть решены специалистом невысокой квалификации. Это могут быть вопросы связанные с интерфейсом пользователя, как решить проблему например загрузки файла или получения каких-либо сведений.
На второй линии поддержки пользователей связана уже с привлечение квалифицированных специалистов, например в случае, когда необходимо перезапустить приложение при возникновении каких-либо ситуаций, решение случаев в которых на первой линии поддержки пользователей не могут решить.
На третей линии обеспечивается поддержка непосредственно уже платформы, тут решаются проблему по работе самой платформы, решение проблем с уязвимостями как платформы, так и самого бизнес-решения.
На четвертой линии поддержки осуществляется непосредственно разработка/доработка самой платформы и ее компонент/модулей.
Ввиду того, что HLF - это платформа на которой реализуется конечные бизнес-решения, то в зависимости от конечно решения зависит к кому необходимо обращаться на определенной линии поддержки.
Если проблемы касаются первой и второй линии, то поддержку осуществляют непосредственно подрядчики, которые осуществляют разработку бизнес-решения на базе платформы. Они обладают всеми знаниями по разрабатываемому решению, но могут не знать особенности работы самой платформы с точки зрения кода, и как следствие не могут осуществлять поддержку на третьем и четвертом уровнях.
Если проблемы касаются третьей линии поддержки, то подобного рода проблемы могут решать внутренняя служба информационной безопасности, например в случае, когда обнаружена уязвимость в платформе, но при этом патч еще не вышел и необходимо обеспечивать безопасное функционирование бизнес-решения.
Если проблемы касаются четвертой линии, то необходимо обеспечивать взаимодействие с консорциумом разработчиков, писать issue и bag reports на github, принимать участие в решении данной проблемы и делать contribute code в репозитории проекта. |
|
|
2.4.4 - Коэффициент технического использования |
|
|
Подготовить отчёт, содержащий либо RTO либо коэффициент технического использования для платформы, либо СБР. |
Необходимо пояснить, что данные параметры целесообразны в рамках БР и отсутствует возможность объективной оценки данных параметров в рамках платформы. |
|
Коэффициент технического использования является необходимой метрикой для решения цели бесперебойного предоставления услуг, который может быть в дальнейшем выражен в SLA. Для вычисления коэффициента необходимо накопить статистические данные о средней наработке на отказ, среднем времени восстановления после отказа, среднем времени технического обслуживания. Имея эти данные можно будет рассчитать коэффициент и представить SLA для бизнес-решения. |
|
|
2.5.1 - Вендоры компонентов платформы |
|
|
Подготовить отчёт, содержащий информация о вендоре платформы и вендорах компонентов платформы, а именно, информация о лицензиях и странах производителя |
Подготовлен отчёт, содержащий информация о вендоре платформы и вендорах компонентов платформы |
|
Официальный список вендоров представлен на сайте : https://www.hyperledger.org/resources/endor-directory, однако ввиду того, что HLF является open source решением, есть множество других коммерческих вендоров и компаний которые могут обеспечивать поддержку, которые не указаны в данном списке. Для российского рынка можно выделить следующие компании/системных интеграторов: КРОК, Ай-Теко, лаборатории в Сбербанк и Норникель. Ввиду того, что технология и решения относительно новые, некоторые лаборатории находятся в инкубационном состоянии, и не освещают о своих достижениях, но при этом способные осуществлять поддержку решений на базе HLF. |
|
|
2.5.2 - Отсутствие ECCN |
|
|
Провести анализ и подготовить отчёт, в котором должно быть представлено присутствие или отсутствие ECCN (Export Control Classification Number) либо европейских аналогов |
Подготовлен отчёт по платформе и её компонентам содержащий наличие у платформы действующих ограничителей связанных с санкционными рисками |
|
Имеется наличие ECCN.
Project: Hyperledger Sent: 2019-04-08 SUBMISSION TYPE: EAR 742.15(b) and 734.3(b)(3) SUBMITTED BY: Stephen Winslow SUBMITTED FOR: The Linux Foundation POINT OF CONTACT: Stephen Winslow TELEPHONE: 415-723-9709 FAX: 415-723-9709 MANUFACTURER(S): The Linux Foundation PRODUCT NAME/MODEL #: Hyperledger ECCN: 5D002 INTERNET LOCATION(S): https://github.com/hyperledger; https://github.com/hyperledger-labs; https://hyperledger.org |
|
