Что, если правило управления доступом, определенное для участника / актива, противоречит правилу управления доступом для транзакции?

У меня вопрос по контролю доступа.

В частности, вопрос касается взаимосвязи между правилами управления доступом, определенными для участников или активов, с одной стороны, и правилами управления активами, определенными для транзакций, осуществляющих доступ к этим участникам / активам.

Вот пример:

Предположим, что сеть Hyperledger Fabric используется для создания какой-то социальной сети для сотрудников компании.

Следующее правило гласит, что у сотрудника есть доступ на запись к своим данным:

rule EmployeesHaveWriteAccessToTheirOwnData {
    description: "Allow employees write access to their own data"
    participant(p): "org.company.biznet.Employee"
    operation: UPDATE
    resource(r): "org.company.biznet.Employee"
    condition: (p.getIdentifier() == r.getIdentifier())
    action: ALLOW
}

Предположим, что доступ для записи осуществляется посредством транзакции «UpdateTransaction». Далее предположим, что (возможно, случайно) значение действия правила управления доступом транзакции UpdateTransaction установлено на «Denied».

rule EmployeeCanSubmitTransactionsToUpdateData {
    description: "Allow employees to update their data"
    participant: "org.company.biznet.Employee"
    operation: CREATE
    resource: "org.company.biznet.UpdateTransaction"
    action: Denied
}

Теперь сложилась такая ситуация:

Каждому сотруднику (согласно правилу 1) предоставляется право изменять свои данные. При этом сотрудникам не разрешается отправлять транзакцию «UpdateTransaction» для изменения данных (см. Правило 2).

Теперь сотрудники не могут изменять свои данные? Или сотрудники по-прежнему могут изменять свои данные, не отправляя транзакцию «UpdateTransaction»?

Другими словами: есть ли способ для участников получить доступ к данным (для которых у них есть права доступа) без использования каких-либо транзакций, определенных в .cto-файле?


access-control hyperledger-composer
person Tommy    schedule 11.05.2018    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Я думаю, ответ в зависимости от обстоятельств.

В вашем примере отказ в доступе к транзакции org.company.biznet.UpdateTransaction приведет к тому, что участники org.company.biznet.Employee не смогут использовать эту транзакцию для обновления своих данные, даже если в противном случае они были бы разрешены.

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

Например, я опробовал это в basic-sample-network, заменив правило EverybodyCanSubmitTransactions на

rule NobodyCanSubmitTransactions {
    description: "Do not allow all participants to submit transactions"
    participant: "org.example.basic.SampleParticipant"
    operation: CREATE
    resource: "org.example.basic.SampleTransaction"
    action: DENY
}

Эта бизнес-сеть включает правило OwnerHasFullAccessToTheirAssets, и я смог использовать транзакцию org.hyperledger.composer.system.UpdateAsset для внесения обновлений для участников, владеющих активом, с помощью команды ,

composer transaction submit -d "$(cat txn.json)" -c party1@basic-sample-network

Где txn.json содержится,

{
  "$class": "org.hyperledger.composer.system.UpdateAsset",
  "resources": [
    {
      "$class": "org.example.basic.SampleAsset",
      "assetId": "ASSET1",
      "owner": "resource:org.example.basic.SampleParticipant#PARTY1",
      "value": "5000"
    }
  ],
  "targetRegistry": "resource:org.hyperledger.composer.system.AssetRegistry#org.example.basic.SampleAsset"
}

Это не сработало бы, если бы вы заблокировали системное пространство имен в своих правилах ACL. (ACL нужно хорошо продумать!)

Еще одна важная вещь, которую следует помнить о списках ACL, заключается в том, что они не применяются, если вы используете метод getNativeAPI для доступа к данным через API Hyperledger Fabric в функциях процессора транзакций.

Ознакомьтесь с справкой по системному пространству имен вместе с ссылка на ACL, плюс есть руководство по ACL, которое может быть интересно, если вы его не видели.

person James Taylor    schedule 14.05.2018