Что если правило контроля доступа, определенное для участника / актива, противоречит правилу контроля доступа для транзакции? - PullRequest
0 голосов
/ 12 мая 2018

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

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

Вот пример:

Предположим, что сеть 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» установлено в «Запрещено»

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-файле?

1 Ответ

0 голосов
/ 14 мая 2018

Я думаю, что ответ, это зависит.

В вашем примере, отказ в доступе к транзакции 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 , которое может бытьИнтересно, если вы этого не видели.

...