Поддержка конфиденциальности Hyperledger Fabric и Composer - полный сценарий

Question

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

Сценарий приложения видит разных продавцов и поставщиков в одной сети (например, я привез посылку из Amazon (разместил заказ), выбранный для доставки курьером A, который за расходыпричина, решил сотрудничать (суб-делегат) с курьером B для одной остановки в многократном пути доставки, запланированном для доставки пакета клиенту).Для этого заказа я хочу, чтобы Amazon, курьер A и B видели детали планов доставки, но я не хочу, чтобы другие продавцы или поставщики видели его.

Теперь вышеупомянутое требование может быть выполнено с использованием ACL Composer (или, аналогично, написание цепного кода с такими же ограничениями в Go в Fabric).Единственная проблема заключается в том, что другие одноранговые поставщики или продавцы будут иметь полный доступ к мировому состоянию и истории регистров на диске, чтобы они могли обойти принудительное применение ACL и получить доступ ко всем данным, связанным с соглашениями других организаций.

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

Тогда у нас есть возможность хранить «личные данные» (цены и т. д.) вне регистра , используя другую систему для их хранения.-of-группа.Это нормально, но другие организации смогут, если мы не будем использовать каналы, понять, с кем мы имеем дело, и примерное количество заказов и поставок.Эта частная информация может быть даже вставлена ​​в сеть блокчейна, используя, начиная с Fabric 1.2, Private Data Collections (PDC) , избегая использования другой внешней системы, поскольку мы можем просто указать, какие данные должны хранитьсякакая организация толькоВ любом случае, данные конфигурации PDC - это просто общие файлы JSON, поэтому каждая организация может понять, с кем вы ведете бизнес.

Наконец, у нас есть Каналы : мы можем создать канал длягруппа Amazon-Courier A - Courier B, которая будет использоваться для этого заказа и заказов в будущем, которые имеют их в качестве актеров.Это выглядит нормально, поскольку данные о заказах теперь распространяются только между партнерами по каналам.Учитывая административную нагрузку по настройке и обслуживанию канала, для такого огромного сценария, как наш, в котором у нас тысячи продавцов и курьеров, могут потребоваться каналы NxM2 с N числом посредников и M курьерами, что кажется невозможным.

Я все понял?Есть другие соображения, которые должны быть сделаны, по вашему мнению?Большое спасибо

Answer 1

Спасибо за ваш добрый ответ, очень признателен.

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

В этом упрощенном сценарии у нас будет тот же цепной код, который потенциально может быть установлен наподтверждающий узел, зависящий только от типа организации (посредник или курьер), а не от конкретного имени организации (идентификатора).Наличие PDC (например, только для данных о стоимости доставки) в этом случае все еще возможно?Насколько я понял, конфигурация коллекции JSON привязана к цепочечному коду, и вы должны указать в ней определенные идентификаторы узлов организации: вам понадобятся разные цепочечные коды "создания заказа" для каждого посредника и разные цепочечные коды "процесса создания создания" для каждогокурьером использовать PDC, сохраняя JSON-доступ только для авторизованных одноранговых узлов и, в то же время, указав идентификатор одноранговых узлов?

Если я не совсем ошибаюсь с предыдущими утверждениями, мне кажется, что механизм ACL (которыйаналогичен условным предложениям if \ then в цепочке кодов, если вы не знакомы с composer), которая позволяет только указанным организациям получать доступ к данным транзакции и регистра, в соответствии с их ролью в транзакции или с данными, - это лучший способзащитить конфиденциальность данных между конкурирующими (но в последующей транзакции, потенциально сотрудничающими) субъектами в одном канале.Единственная проблема состоит в том, что регистр распределяется между всеми одноранговыми узлами организации, чем его можно непосредственно прочитать на одноранговом диске, обходя контроль доступа к данным ACL.Может быть, только с помощью механизма шифрования личных данных, с ключами, доступными только для конкретной транзакции \ заинтересованного лица, это может быть решено (или с разными каналами, но комбинации между посредниками и курьерами могут сделать это очень сложно).

ПустьМне известно, если вы согласны или если вы заметили, где я не прав, и как эта проблема на самом деле решается в Hyperledger.Большое спасибо!A

Answer 2

Я думаю, что вы частично правы, согласно вашему сценарию, когда вы хотите, чтобы две организации (Amazon и Courier) и, скажем, 3 партнера (1 от Amazon и 2 от курьера A и курьера B) для обмена данными в этом случае Сбор личных данных будет лучшим вариантом (я работал над матрицей HL, не могу комментировать ACL).Почему?

1. Вы не хотите, чтобы вся бизнес-логика была разной, только некоторая часть данных была бы приватной.Таким образом, если вы создаете новый канал, вы должны установить новый цепной код (или тот же самый снова).
2. PDC позволяет использовать сценарии, в которых вы хотите, чтобы все участники канала видели транзакцию во времясохранение части данных в секрете.

см. Когда использовать коллекцию внутри канала вместо отдельного канала

И еще одна вещь, которую вы упомянули,«В любом случае, данные PDC являются общими файлами конфигурации JSON, поэтому организация может понять, с кем вы работаете». Это не так , только экземпляр org / peer, создающий цепной код, имеет доступ к файлу collection-config.json, так как мы не создаем экземпляр кода цепочки для всех org / peer, поэтому вы можете думать только о Amazonиметь доступ к файлу json и, следовательно, информацию о ", с которым вы ведете бизнес "