Динамический контроль доступа в Hyperledger Fabric - PullRequest
1 голос
/ 13 марта 2019

Я работаю с Hyperledger Fabric и разрабатываю Chaincode в Golang. У меня есть следующий вариант использования, и я не уверен, как реализовать это в Fabric.

Предположим, у меня есть одноранговые организации Bank1, Bank2 и Bank3. Я хочу разработать систему, в которой каждый из них будет хранить информацию о клиенте (где клиент является владельцем банковского счета). Как правило, я не хотел бы, чтобы Bank2 имел доступ к клиентам Bank1 - но если клиент каким-либо образом вызывает определенный вызов функции, bank2 должен иметь возможность получать информацию этого клиента из bank1 (учитывая, что все банки совместно используют канал)

Как мне добиться чего-то подобного в коде цепи?

Я смотрел на ABAC, я не уверен, как я могу обновить атрибут организации, чтобы разрешить доступ к определенному клиенту на основании того, что он предпринял действие

Спасибо

1 Ответ

1 голос
/ 13 марта 2019

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

Другое решение без необходимости реализовывать вещи из вашей цепочки блоков - это использовать частные коллекции данных, что является улучшением, внесенным в Fabric в версии 1.2. Более подробная информация здесь: https://hyperledger -fabric.readthedocs.io / ru / release-1.2 / private-data / private-data.html

Обновление:

Безопасно ли вызывать внешние apis из кода цепи? Как мне сохранить секретные ключи / токены?

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

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

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

Обновление 2:

Возможно ли, чтобы кто-то из организации «запросил» бухгалтерскую книгу или прочитал ее состояние напрямую, а НЕ через код цепи?

Краткий ответ: да, это возможно. Все, что записывается в блокчейне, будет доступно для чтения администраторам коллег и любому, кто имеет контроль над закрытыми ключами. НО вот где архитектура вступает в игру: если вам не нужно что-то написанное в блокчейне, просто не пишите это. Это зависит от того, для чего вы хотите блокчейн. Если это просто для подтверждения того, что информация была передана, просто сохраните необходимую информацию: «bankA поделился информацией о пользователе B с bankC». Фактическая информация не должна быть сохранена в блокчейне. Если вам нужна информация в блокчейне и вы хотите, чтобы она была конфиденциальной, я думаю, что лучшим решением будет использование частных коллекций данных, и имейте в виду, что на самом деле частные данные не подлежат консенсусу, потому что частные данные сохраняются в БД стороны только в узлах / организациях, участвующих в частной транзакции, а не в каждом узле.

...