Контроль доступа на основе блокчейна – зачем нам для авторизации блокчейн?

Контроль доступа на основе блокчейна – зачем нам для авторизации блокчейн?

Источник · Перевод автора

Многие стартапы должны обосновать, почему им нужен блокчейн для их идеи. Почему нет другого пути? Почему это должна быть эта технология?

Этот вопрос задается все реже, потому что мы поняли, что в некоторых случаях блокчейн может быть полезен для нас. Блокчейн дает нам возможность управлять сложными бизнес-процессами, которые ранее были возможны только через грязные и сложные обходные пути. Однако ясно, что эта технология, несмотря на свою веру в нее, не является чудодейственным инструментом для всего.

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

Мы не создаем проблемы, мы их решаем!

ОСНОВНАЯ ИДЕЯ ОБЩЕСТВЕННОЙ БЛОКЧЕЙН-СЕТИ

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

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

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

КОНТРОЛЬ ДОСТУПА НА ОСНОВЕ РОЛИ (RBAC)

Современные системы часто полагаются на управление доступом на основе ролей (Role Based Access Control, RBAC). Обещание состоит в том, чтобы больше не связывать полномочия с чрезвычайно статичными удостоверениями, а с динамическими ролями, которые, в свою очередь, назначаются удостоверениям, то есть пользователям.

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

ИСПОЛЬЗОВАНИЕ ПРАВИЛ ВМЕСТО РОЛЕЙ

Вы можете использовать управление доступом на основе атрибутов (Attribute Based Access Control, ABAC) для более точной и предопределенной обработки полномочий через правила.

«Управление доступом на основе атрибутов (ABAC), также известное как управление доступом на основе политик, определяет парадигму контроля доступа, согласно которой права доступа предоставляются пользователям посредством использования политик, которые объединяют атрибуты вместе. Политики могут использовать атрибуты любого типа (атрибуты пользователя, атрибуты ресурса, объект, атрибуты среды и так далее). Эта модель поддерживает логическую логику, в которой правила содержат операторы «IF, THEN» о том, кто делает запрос, ресурс и действие. Например: ЕСЛИ запросчик является менеджером, ТО разрешить доступ на чтение / запись к конфиденциальным данным. В отличие от управления доступом на основе ролей (RBAC), в котором используются предопределенные роли, которые несут определенный набор привилегий, связанных с ними и которым назначаются субъекты, основным отличием ABAC является концепция политик, которые выражают сложный набор логических правил которые могут оценить множество различных атрибутов» (1)

Мы используем комбинацию решений RBAC и ABAC: на основе ролей, чтобы предоставить пользователям динамический доступ к ресурсу, и на основе атрибутов, чтобы определить, что модульное разрешение может делать с ресурсом (при необходимости). Это обеспечивает высочайшую гибкость. Хотя можно разделить разрешения на их модульные части, также можно использовать стандартизированные шаблоны поведения, такие как наследование разрешений. Намерение, описываемое объединением операции и объекта, обеспечивается в блокчейне «намеренным хэшем», благодаря чему обеспечивается уникальность авторизации.

Полномочия («разрешения») могут быть сгруппированы в роли в соответствии с RBAC. Роли могут содержать подчиненные роли. Это позволяет нам быстро и эффективно назначать пакет связанных полномочий (например, для проекта или конкретной должности в компании). Это позволяет избежать ошибок и оптимизировать процессы, например, при подключении новых сотрудников или вводе новых проектов как для внутренних, так и для внешних сотрудников.

ОПЯТЬ ЖЕ, ЗАЧЕМ НАМ НУЖЕН БЛОКЧЕЙН ДЛЯ ЭТОГО? КАКОЙ У ТЕБЯ ЖУРНАЛ (LOG)?

Используя блокчейн в качестве интеллектуального «Списка контроля доступа», мы можем проверять список в любое время, в то время как мы можем быть уверены в его целостности данных. Современные системы не полностью покрыты из-за отсутствия кроссплатформенной функциональности и чувствительных к манипуляциям структур данных. Итерируя блокчейн-транзакции, также очень легко определить, у кого были какие полномочия и в какое время. В зависимости от требуемых настроек безопасности и конфиденциальности, любое количество информации может быть зарегистрировано. Например, кто и к какому времени обратился к какому-либо ресурсу или кому он передал полномочия. Этим полным протоколом никогда нельзя манипулировать, и он дает нам большую добавленную стоимость для аудита при соблюдении защиты данных.

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

Это означает, что разрешения могут запрашиваться пользователями и подтверждаться другими пользователями. Разница в том, что они не обрабатываются с помощью распространенной сегодня системы тикетов. Запрос отправляется непосредственно в виде транзакции в сеть блокчейна. Например, мне (как сотруднику) нужны разрешения для настройки нового модуля Oracle ERP, или мне нужно открыть дверь нашей комнаты собраний, потому что я забронировал ее через наш календарь. Но совершенно не зависит от структуры данных: кто-то должен дать мне эти разрешения, желательно как можно скорее. Кто может это сделать? Конечно, наши админы! Зачем? Мы возложили на них ответственность, потому что процессы не допускали другого рабочего процесса. Однако сегодня они это делают.

Теперь не только администраторы имеют возможность отвечать на эти запросы, но и любой человек, который действительно отвечает за это, может реагировать. Ответственные могут быть разными для разных разрешений. Например, могут существовать типы полномочий для конкретных проектов или отделов, которыми должен управлять руководитель проекта или отдела. Кто-то отвечает за модули Oracle ERP, кто-то другой отвечает за умные блокировки отдела. Предоставить общий доступ с разделенной ответственностью. Кроме того, здесь вступает в действие протокол, поскольку каждый запрос и каждое подтверждение надежно сохраняются в блокчейне как транзакция.

Сколько и какие подтверждения необходимы для успешного назначения полномочий, может быть определено с помощью предварительно определенных требований. Это условия, основанные на логических фактах, таких как «сертификатору необходимо владеть определенным атрибутом» (например, абстрактный атрибут «admin» или «projectmanager-project-x»). Интеллектуальная автоматизация (построенная по заранее определенному коду интеллектуального контракта) также может использоваться для создания надежных подтверждений. Это означает, что интеллектуальные контракты (выполнение по цепочке) автоматизируют процесс назначения и отзыва прав при определенных условиях, что значительно сокращает избыточную и подверженную ошибкам работу. Решение, если условие (или группа условий) выполнено, делается распределенным по цепочке блоков, чтобы ни одна третья сторона не смогла скомпрометировать этот процесс.

Вы видите, что блокчейн может представлять не только интеллектуальный список контроля доступа, но и настоящую «сеть доступа». Общий доступ через совместную ответственность, основанный на ненадежном протоколе, из которого всегда может быть запрошено текущее состояние всех авторизаций. – Разве это не здорово?

КАКОЙ БЛОКЧЕЙН ВЫ ИСПОЛЬЗУЕТЕ?

Как партнер Oracle мы создаем наш первый прототип на платформе Oracle Blockchain. Это блокчейн Hyperledger, который можно администрировать через Oracle Cloud. Hyperledger позволяет создать корпоративную сеть цепочки блоков для вашей собственной компании и за ее пределами. Это частный / федеративный блокчейн.

Если вы ознакомитесь с основными понятиями Hyperledger, вы упомянете «Центр сертификации» (Certification Authority, CA) и «Поставщик услуг членства» (Membership Service Provider, MSP), используемый для определения и идентификации утвержденных членов частной или федеративной блокчейн-сети. Эти центры сертификации в основном являются частью IT-архитектуры компании и позволяют легко интегрировать Hyperledger в вашу личную среду.

www.blockaxs.com

(1) – https://en.wikipedia.org/wiki/Attribute-based_access_control