Membership Service Providers (MSP)

В этом документе собраны детали по установке MSP, а также связанные с этим best practicies.

MSP — это компонент Hyperledger Fabric, который абстрагирует membership-операции (то есть операции, связанные с участниками сети).

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

Блокчейн-сеть Hyperledger Fabirc может управляться одним или несколькими MSP. Это обеспечивает модульность membership-операций, а также взаимодействие между несколькими разными membrship-стандартами и архитектурами.

В оставшейся части этого документа поговорим об установке реализации MSP, поддерживаемой HL Fabric, и обсудим best practicies, связанные с его использованием.

Настройка MSP

Чтобы установить экземпляр MSP, его конфигурация должна быть указана локально на каждом пире и orderer’е, чтобы:

  • обеспечить подписание пиров и orderer’ов,
  • позволить каналам подтверждать identity пиров, orderer’ов и клиентов
  • обеспечить проверку соответствующей верификации подписей (то есть обеспечить аутентификацию) всеми участниками каналов всех других участников.

Для начала, каждый MSP должен иметь имя, чтобы на него можно было ссылаться в сети (например так: msp1, org2, или org3.divA). Это имя, с помощью которого в канале будут указаны membership rules MSP (правила членства), представляющего консорциум, организацию или подразделении организации. На это имя также часто ссылаются как на MSP Identifier (идентификатор MSP) или MSP ID. MSP Identifier должен быть уникальным для каждого экземпляра MSP. Например, если при создании системного канала обнаружится, что два разных экземпляра MSP имеют один и тот же MSP Identifier, то установка orderer-службы будет прервана.

В случае стандартной реализации MSP, необходимо задать некоторый набор параметров, чтобы можно было проводить валидацию identity (сертификата) и верификацию подписей. Эти параметры можно определить по RFC5280, включая:

  • список само-подписанных (X.509) CA-сертификатов для образования root of trust (основы доверия)
  • Список сертификатов X.509, представляющих промежуточные CA, которых данный провайдер выбрал для валидации сертификатов; эти сертификаты должны быть сертифицированы ровно одним из сертификатов, образующих root of trust; промежуточные CA — опциональные параметры
  • Список сертификатов X.509, представляющих администраторов данного MSP с verifiable certificate path (проверяемым сертификационным путем?) к ровно одному из образующих root of trust CA сертификатов; владельцы данных сертификатов имеют право запросить изменения к данной MSP конфигурации (например к корневым CA, то есть тем, которые образовывают root of trust, или к промежуточным CA)
  • Список Organizational Units, которые участники данного MSP должны включить в свои сертификаты X.509; это опциональный параметр, который используется когда, например, несколько организаций использвуют один и тот же root of trust, те же промежуточные CA и зарезервировали OU-поля для своих участников
  • Список из certificate revocation lists (CRLs, списки аннулирования сертификатов), каждый из которых соответствует ровно одному корневому или промежуточному MSP CA; это опциональный параметр
  • Список само-подписанных (X.509) сертификатов для образования TLS root of trust для TLS-сертификатов
  • Список сертификатов X.509, представляющих промежуточные TLS CA, выбранных данным провайдером; эти сертификаты должны быть сертифицированы ровно одним из сертификатов, образующих TLS root of trust; промежуточные CA — опциональные параметры

Валидные identities для данного экземпляра MSP должны удовлетворять следующим требованиям:

  • Они должны быть в форме X.509 сертификатов с verifiable certificate path до ровно одного из корневых сертификатов;
  • Они не должны быть включены ни в один CRL;
  • Они должны перечислить один или более Organizational Units MSP-конфигурации в поле OU их структуры сертификата X.509.

Для получения дополнительной информации по валидности identities в текущей реализации MSP, обратитесь к MSP Identity Validity Rules.

Чтобы позволить узлу, на котором установлен экземпляр MSP, подписывать и аутентифицировать, необходимо задать:

  • Ключ цифровой подписи (сейчас поддерживаются только ECDSA-ключи), и
  • Сертификат X.509 узла, который является валидной identity данного MSP.

Важно заметить, что MSP identities никогда не просрочиваются; они могут быть отозваны только добавлением в CRLs. Также в данный момент не поддерживается отзыв TLS-сертификатов.

Как сгенерировать MSP сертификаты и ключи цифровой подписи?

Openssl может использоваться, чтобы генерировать X.509 сертификаты и ключи. Hyperledger Fabric не поддерживает RSA ключи и сертификаты.

Можно использовать программу cryptogen, описанную в Приступая к работе.

Hyperledger Fabric CA может использоваться, чтобы генерировать необходимые для настройки MSP ключи и сертификаты.

Установка MSP на стороне пира и orderer’а

Чтобы установить локальную MSP (или для пира, или для orderer’а), администратор должен создать директорию (например, $MY_PATH/mspconfig), содержащую 6 поддиректорий и 1 файл:

  1. директория admincerts, чтобы хранить PEM-файлы, каждый из которых соответствует сертификату администратора
  2. директория cacerts , чтобы хранить PEM-файлы, каждый из которых соответствует корневому CA-сертификату
  3. (опционально) директория intermediatecerts , чтобы хранить PEM-файлы, каждый из которых соответствует промежуточному CA-сертификату
  4. (опционально) файл config.yaml для настройки поддерживаемых Organizational Units и identity classifications (смотрите соответствующие секции ниже).
  5. (опционально) директория crls , чтобы хранить CRLs
  6. директория keystore , чтобы хранить PEM-файл с ключом цифровой подписи узла. Обращаем внимание, что RSA-ключи не поддерживаются
  7. директория signcerts , чтобы хранить PEM-файл X.509 сертификатом узла
  8. (опционально) директория tlscacerts , чтобы хранить PEM-файлы, каждый из которых соответствует корневому TLS-сертификату
  9. (опционально) директория tlsintermediatecerts , чтобы хранить PEM-файлы, каждый из которых соответствюет промежуточному TLS-сертификату

В конфигурационном файле узла (core.yaml для пира, и orderer.yaml для orderer’а), необходимо указать путь к mspconfig директории, а также MSP-идентификатор для MSP-узла. Ожидается, что путь к mspconfig относителен FABRIC_CFG_PATH и дан как значение параметра mspConfigPath для пира, и LocalMSPDir для orderer’а. Идентификатор MSP узла задается как параметр localMspId для пира и LocalMSPID для orderer’a. Эти переменные могут быть переопределены через переменные окружения с использованием префикса CORE для пира (например, CORE_PEER_LOCALMSPID) и префикса ORDERER для orderer’a (например, ORDERER_GENERAL_LOCALMSPID). Заметьте, что в случае orderer’a необходимо сгенерировать и передать orderer’у genesis-блок системного канала. Нужды MSP-конфигурации в этом блоке указаны детально в следующей секции.

Перенастройка локальной MSP возможна только вручную, и нуждается в перезагрузке пира или orderer’а. В следующих релизах мы планируем добавить online/динамическую перенастройку (например, без нужды в остановке узла с помощью управляемого узлом системного чейнкода).

Organizational Units

Для настройки списка Organizational Units (OU, организационные подразделения), который действительные участники MSP должны включить в свой сертификат X.509, config.yaml должен указать идентификаторы organizational units. Пример:

OrganizationalUnitIdentifiers:
  - Certificate: "cacerts/cacert1.pem"
    OrganizationalUnitIdentifier: "commercial"
  - Certificate: "cacerts/cacert2.pem"
    OrganizationalUnitIdentifier: "administrators"

Этот пример определяет 2 OU-идентификатора: commercial и administrators. MSP identity действительна, если она содержит хотя бы один из этих OU-идентификаторов. Поле Certificate — путь к CA- или промежуточному CA- сертификату, который подтверждает identities с данными OU. Путь задается относительно корневой директории MSP и не может быть пустым.

Классификация Identity

Стандартная реализация MSP позволяет организациям классифицировать identities на клиентов, администраторов, пиров, и orderer’ов, базируясь на OU их x509 сертификатов.

  • Identity должна быть классифицирована как клиент, если она создает транзакции в сети.
  • Identity должна быть классифицирована как администратор, если она решает административные задачи, например, присоединение пира к каналу или подписывание транзакции по обновлению конфигурации канала.
  • Identity должна быть классифицирована как пир, если она endorses (одобряет) или commits (фиксирует) транзакции.
  • Identity должна быть классифицирована как orderer, если она принадлежит orderer-узлу.

Чтобы определить клиентов, администраторов, пиров и orderer’ов данного MSP, файл config.yaml должен быть соответственно настроен. Вы можете найти пример секции NodeOU файла config.yaml ниже:

NodeOUs:
  Enable: true
  # Для каждой классификации identity укажите OU-идентификатор
  # Вы можете опционально указать, что OU-идентификатор должен быть выпущен конкртеным CA
  # или промежуточным сертификатом вашей организации. Однако обычно конкретный сертификат НЕ указывают.
  # не указывая конкретный сертификат, вы сможете добавить другие CA или промежуточные сертификаты позже,
  # без нужды в перевыпуске всех удостоверений.
  # Если вы все же хотите так сделать, смотрите на поле сертификат (оно закоментировано).
  ClientOUIdentifier:
    # Certificate: "cacerts/cacert.pem"
    OrganizationalUnitIdentifier: "client"
  AdminOUIdentifier:
    # Certificate: "cacerts/cacert.pem"
    OrganizationalUnitIdentifier: "admin"
  PeerOUIdentifier:
    # Certificate: "cacerts/cacert.pem"
    OrganizationalUnitIdentifier: "peer"
  OrdererOUIdentifier:
    # Certificate: "cacerts/cacert.pem"
    OrganizationalUnitIdentifier: "orderer"

Identity классификация включена, когда NodeOUs.Enabletrue. Тогда OU-идентификатор клиента (администратора, пира, orderer’а) определяется установкой свойств ключа NodeOUs.ClientOUIdentifier (NodeOUs.AdminOUIdentifier, NodeOUs.PeerOUIdentifier, NodeOUs.OrdererOUIdentifier):

  1. OrganizationalUnitIdentifier: такое значение должен содержать x509 сертификат, чтобы он был классифицирован как клиент (администратор, пир, orderer соответственно). Если это поле пусто, то классификация не происходит.
  2. Certificate: (Опционально) Путь к CA- или промежуточному CA-сертификату с помощью которого identity клиента (пира, администратора или orderer’а) должна быть подтверждена. Путь задается относительно корневой MSP-директории. Только один сертификат может быть указан. Если вы не зададите это поле, то identities подтверждаются любым CA, определенным в MSP конфигурации организации, что может пригодиться в будущем, если нужно будет добавить еще один CA- или промежуточный сертификат.

Заметьте, что если секция NodeOUs.ClientOUIdentifier (NodeOUs.AdminOUIdentifier, NodeOUs.PeerOUIdentifier, NodeOUs.OrdererOUIdentifier) отсутствует, то тогда классификация не применяется. Если NodeOUs.Enabletrue и ключи классификации не определены, то тогда identity-классификация считается выключенной.

Identities могут использовать organizational units чтобы быть классифицированными как клиент, администратор, пир, или orderer. 4 классификации являются взаимно-исключающими. Необходимо обеспечить возможность применения 1.1-каналов, прежде чем identities могу быть классифицированы как клиенты или пиры. Необходимо обеспечить возможность применения 1.4.3-каналов, прежде чем identities могу быть классифицированы как администраторы или orderer’ы.

Классификации позволяют identities быть идентифицированными как администраторы (и выполнять административные действия) без хранения сертификата в директории MSP admincerts. Вместо этого, директория admincerts может оставаться пустой и администраторы могут быть созданы регистрацией identities с OU администратора. Сертификаты в директории admincerts все еще будут давать права администратора своим владельцам, если они обладают OU клиента или администратора.

Установка MSP канала

При создании системы должны быть указаны верификационные параметры всех MSP, встречающихся в сети, так же они должны быть включены в genesis-блок системного канала. Напоминаем, что верификационные параметры MSP состоят из MSP-идентификатора, root of trust сертификатов, промежуточных CA и сертификатов администраторов, OU-спецификации и CRLs. Genesis-блок системного канала передается orderer’ам в фазу их установки и позволяет им аутентифицировать запрос по созданию канала. Orderer’ы отклонят создание genesis-блока системного канала, если он содержит две MSP с одним и тем же идентификатором. Тогда инициализация ноды прервется.

Для несистемных каналов (application channel, прикладных каналов), в genesis-блоке канала должны присутствовать верификационные компоненты только тех MSP, которые управляют каналом. Обратите внимание, что проверка корректности конфигурации MSP — это обязанность приложения. Проверку надо сделать до того, как предлагать пирам присоединяться к каналу.

При настройке канала с помощью configtxgen можно настроить и MSP канала, поместив верификационные параметры MSP в директорию mspconfig и указав путь к ним в соответствующей секции configtx.yaml.

Перенастройка MSP канала, включая объявления certificate revocation lists, связанных с CAs данного MSP, достигается через создание объекта

config_update владельцем одного из сертификатов администратора MSP. Приложение клиента, управляемое его администратором,

затем объявит обновление канала.

Лучшие практики

В этой секции мы обсудим лучшие практики по настройке MSP в часто встречающихся сценариях.

1) Сопоставление организаций и MSP

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

  • Одна организация использующая несколько MSP. Это включает случай, когда организация насчитывает несколько подразделений, каждый из которых имеет свой MSP (из соображений приватности или для достижения более гибкого управления). В этом случае пир может принадлежать только одному MSP, и не распознает пиров с identities других MSPs как пиров этой же организации. В следствии этого пиры могут общаться по внутриорганизационному gossip-протоколу только с пирами своего же подразделения.
  • Несколько организаций, использующих один MSP. Это включает случай, когда консорциум организаций управляется похожей membership-архитектурой. В этом случае пиры будут распространять внутриорганизационные сообщения пирам, имеющим ту же MSP identity, не отличая пиров своей организации от пиров чужой. Такое ограничение связано со степенью детализации определения MSP и/или конфигурацией пиров.

2) Одна организация имеет разные подразделения (organizational units), ** **к которым она хочет дать доступ разным каналам

Существует два способа решить эту проблему:

  • Определить один MSP, чтобы предоставить membership (членство) всем участникам организации. Конфигурация данного MSP будет состоять из списка корневых CA, промежуточных CA и сертификатов администратора; membership identities будут включать organization unit (OU) соответствующего участника. Тогда политики могут быть определены, чтобы разделить участников по ролям (role), типа: пир, администратор, клиент, orderer, member, и эти политики могут определить политики по записи/чтению в канал или политики подтверждения чейнкода. Пока что вы не можете указать нестандартные OU в profile-секции configtx.yaml. Ограничение этого подхода такое же, как и в случае нескольких организаций, использующих один MSP в пункте 1)
  • Определить отдельный MSP для каждого подразделения. Для этого придется для каждого подразделения указать из список корневых CA, промежуточных CA и сертификатов администратора, так, что никакой из путей к сертификатам не будет присутствовать сразу в двух MSP. Это означает, что, например, для каждого подразделения необходим свой уникальный промежуточный CA. Минус этого подхода в сложности по управлению несколькими MSP вместо одного, но зато это решает проблему предыдущего подхода. Также можно определить MSP для каждого подразделения, используя OU extension (расширение к OU) в конфигурации MSP.

3) Отделение клиентов от пиров одной и той же организации.

В большом количестве случаев необходимо, чтобы тип identity мог быть выведен из самой identity (например, если нужно гарантировать, что подтверждения пришли от пиров, а не от клиентов или узлов, занимающихся исключительно ordering’ом).

Существует ограниченная поддержка таких требований.

Один способ достичь такого разделения - создать отдельный промежуточный CA и настроить отдельный MSP для каждого типа узлов - одно CA+MSP для клиентов и одно для пиров/orderer’ов. Каналы, которые должны быть доступны организации, обязаны хранить оба MSP, а политики подтверждения - только MSP пиров.p-протоколу не будет сильно затронуто, так как пиры одной и той же организации будут принадлежать одному Таким образом, организации будут сопоставлены два экземпляра MSP, что повлияет на то, как пиры и клиенты взаимодействуют друг с другом.

Общение по внутриорганизационному gossip-протоколу не будет сильно затронуто, так как пиры одной и той же организации будут принадлежать одному MSP. Пиры могут ограничить выполнение конкретных системных чейнкодов по политикам, установленным на локальном MSP. Например, выполнять запрос “joinChannel”, только если запрос был подписан администратором локальной MSP, который может быть только клиентом (то есть запрос должен быть создан конечным пользователем). Мы можем обойти эту проблему, если примем, что только администраторы MSP, отвечающего за пиры и orderer’ы, могут быть его клиентами.

Также при использовании такого подхода надо учесть, что пиры авторизуют запросы по регистрации событий (event registration requests), основываясь на информации из их локальной MSP о создателе запроса. Так как создатель запроса - клиент, он не будет принадлежать к локальному MSP, поэтому запрос будет отклонен.

4) CA-сертификаты и сертификаты администраторов.

Важно, чтобы MSP-сертификаты администраторов не совпадали с сертификатами root of trust или промежуточными CA. Отделять обязанности по управлению membership-компонентами от обязанностей по выпуску и валидации сертификатов - довольно распространенная практика, соблюдаемая из соображений безопасности.

5) Блокирование промежуточного CA.

Как было упомянуто выше, перенастройка MSP осуществляется при помощи механизмов перенастройки (ручной перенастройки локальных экземпляров MSP и через корректно созданные config_update-сообщения для экземпляров MSP конкретного канала). Сделать так, чтобы промежуточный CA не мог использоваться MSP для валидации identity, можно двумя путями:

  1. Перенастроить MSP так, чтобы он больше не содержал промежутчный CA в списке доверенных промежуточных CA-сертификатов. Для локально настроенного MSP - удалить сертификат из директории intermidiatecertificates.
  2. Перенастроить MSP так, чтобы хранить CRL, созданный root of trust, отзывающий промежуточный CA-сертификат.

В текущей реализации MSP поддерживается только первый способ как наиболее простой и не нуждающийся в создании CRL.

6) CA и TLS CA

Корневые сертификаты, связанные с MSP identities, и корневые сертификаты MSP TLS (и связанные промежуточные CA) должны быть объявлены в разных директориях, чтобы избежать смешение разных классов сертификатов. Не запрещается переиспользовать один и тот же CA и для MSP identities, и для TLS сертификатов; однако этого лучше избегать при промышленной эксплуатации.