Ролевое управление доступом (RBAC)

Что такое ролевое управление доступом (RBAC) в криптоиндустрии?

Ролевое управление доступом (RBAC) — это модель безопасности, в которой разрешения назначаются ролям, а не напрямую каждому отдельному пользователю, кошельку, сервисному аккаунту, смарт-контракту или оператору.

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

В глоссарии NIST по RBAC эта модель определяется как система, в которой разрешенные действия с ресурсами связываются с ролями, а не с личностями отдельных субъектов.

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

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

Затем к этим ролям привязывают пользователей, кошельки, ботов, серверы или контракты.

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

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

Простое определение ролевого управления доступом (RBAC)

Ролевое управление доступом (RBAC) — это способ управлять разрешениями, назначая пользователям или аккаунтам роли с заранее заданными правами доступа.

Вместо того чтобы отдельно определять, что разрешено делать каждому человеку, RBAC определяет допустимые действия для каждой роли.

Например, подписант казначейства может одобрять платежи, но не развертывать обновления смарт-контрактов.

Специалист по обновлению смарт-контрактов может планировать обновления, но не переводить средства из казначейства.

Агент поддержки может просматривать состояние аккаунта, но не менять настройки вывода средств.

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

Такое разделение ограничивает ущерб, который может нанести один скомпрометированный аккаунт.

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

Почему RBAC важен в криптовалютной сфере

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

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

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

Каждой из этих систем необходим строгий контроль доступа.

RBAC помогает командам не предоставлять широкие права администратора всем сотрудникам проекта.

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

Для пользователей надежный RBAC снижает вероятность того, что один скомпрометированный сотрудник, разработчик или сервисный аккаунт нанесет ущерб целой платформе или протоколу.

Для создателей проектов RBAC — важная часть базовой операционной безопасности, безопасности смарт-контрактов и управления доверием.

Как работает RBAC

Работа с RBAC начинается с определения ресурсов, которые нужно защитить.

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

Затем команда определяет действия, которые можно выполнять с этими ресурсами.

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

Далее команда объединяет эти действия в роли.

Затем пользователям, кошелькам, сервисным аккаунтам или контрактам назначают роли.

Когда кто-либо пытается выполнить действие, система проверяет, есть ли у этого субъекта необходимая роль.

Если у роли есть нужное разрешение, действие выполняется; если нет — система его отклоняет.

Основные компоненты RBAC

Основные компоненты RBAC — субъекты, роли, разрешения, ресурсы, сеансы и политики.

Субъект — это человек, кошелек, бот, сервисный аккаунт, смарт-контракт, процесс валидатора или сервер, который запрашивает доступ.

Роль — это именованная группа разрешений.

Разрешение — это одобренное действие с ресурсом.

Ресурс — это объект, который необходимо защитить.

Сеанс — это активное использование субъектом одной или нескольких ролей.

Политика — это набор правил, определяющих, как роли создаются, назначаются, проверяются и отзываются.

При грамотном проектировании этих компонентов RBAC упрощает управление доступом и аудит.

RBAC в смарт-контрактах

RBAC широко используют в смарт-контрактах для контроля привилегированных функций.

Например, в контракте токена может быть роль эмитента, которой разрешено создавать новые токены.

В контракте управления может быть роль исполнителя, которому разрешено выполнять одобренные предложения.

В контракте моста может быть роль ретранслятора, которому разрешено отправлять проверенные сообщения.

В DeFi-протоколе может быть роль ответственного за безопасность, которому разрешено приостанавливать рискованные функции в чрезвычайной ситуации.

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

В документации OpenZeppelin по API AccessControl описан механизм ролевого управления доступом для каждого контракта, в котором можно создавать несколько иерархических ролей и назначать их разным аккаунтам.

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

RBAC и смарт-контракты Ownable

Ownable — это простой шаблон контроля доступа, при котором административные полномочия принадлежат одному аккаунту владельца.

RBAC гибче: он позволяет создавать разные роли с отдельными разрешениями.

Ownable может подойти для быстрых тестов или очень небольших контрактов.

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

Например, аккаунт, который может приостановить протокол, не должен автоматически иметь возможность выпускать токены или выводить средства из казначейства.

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

RBAC обеспечивает разделение обязанностей.

Такое разделение снижает вероятность того, что компрометация одного ключа приведет к полной компрометации протокола.

RBAC и принцип минимальных привилегий

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

RBAC — один из самых практичных способов применить этот принцип.

В рекомендациях Kubernetes по RBAC советуют предоставлять пользователям и сервисным аккаунтам минимальные права и использовать только разрешения, необходимые для их работы.

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

Разработчику, которому нужен только доступ для чтения, не следует разрешать переводить средства.

Бот мониторинга не должен иметь возможность менять владельца контракта.

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

Благодаря принципу минимальных привилегий RBAC становится реальным инструментом безопасности, а не просто списком разрешений.

RBAC и разделение обязанностей

Разделение обязанностей означает, что ни одна роль не должна обладать достаточными полномочиями, чтобы самостоятельно выполнить весь опасный процесс.

Например, одна роль может создавать запрос на вывод средств, другая — проверять его, а мультисиг-кошелек — одобрять.

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

Это снижает риски инсайдерских действий и компрометации аккаунтов.

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

В криптосфере разделение обязанностей полезно для управления казначейством, работы мостов и валидаторов, подписания релизов, выпуска токенов и реагирования на чрезвычайные ситуации.

RBAC позволяет реализовать это разделение за счет четко определенных ролей с отдельными разрешениями.

В надежной криптоинфраструктуре одной роли не предоставляют неограниченный контроль одновременно над средствами, кодом и инфраструктурой.

RBAC и мультисиг-кошельки

Мультисиг-кошелек требует нескольких подтверждений перед исполнением транзакции.

RBAC и мультисиг-кошельки хорошо дополняют друг друга, но решают разные задачи.

RBAC определяет, у кого какие разрешения.

Мультисиг определяет, сколько одобренных подписантов должны согласиться на отправку транзакции.

Роль казначея может разрешать создание запроса на платеж, но мультисиг-кошелек все равно может требовать подтверждения от нескольких подписантов.

Роль администратора протокола может разрешать планирование обновления, но для окончательного исполнения могут требоваться временная задержка и одобрение мультисиг-кошелька.

Сочетание этих механизмов обеспечивает более надежный контроль, чем каждый из них по отдельности.

В криптосистемах с крупными суммами RBAC обычно следует дополнять мультисигом, временными задержками, мониторингом и четкими правилами управления.

RBAC и DAO

DAO могут использовать RBAC для управления делегированными полномочиями.

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

Благодаря таким ролям DAO может действовать быстрее, чем при необходимости проводить голосование всего сообщества по каждому небольшому вопросу.

Однако полномочия делегированных ролей должны быть ограничены и прозрачны.

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

Если комитет может перемещать средства или обновлять контракты без надлежащего контроля, децентрализация DAO может оказаться лишь формальной.

RBAC помогает DAO работать, но слишком широкие полномочия ролей могут скрывать централизацию.

Продуманная система RBAC в DAO должна обеспечивать прозрачность полномочий для держателей токенов и пользователей.

RBAC на криптоплатформах

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

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

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

Сотрудник поддержки может просматривать статус обращения, но не должен одобрять крупные выводы средств.

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

Оператор казначейства может подготавливать переводы, но не должен исполнять их единолично.

RBAC помогает снизить угрозы со стороны инсайдеров и риск операционных ошибок.

Он также упрощает аудит, поскольку платформа может показать, какая роль выполнила каждое действие.

RBAC и безопасность API

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

RBAC важен для API, поскольку сама аутентификация не подтверждает, что пользователь вправе выполнить запрошенное действие.

В рекомендациях OWASP по API1:2023 — нарушению авторизации на уровне объектов объясняется, что злоумышленники могут использовать API, подменяя идентификаторы объектов, если эндпоинты неправильно проверяют разрешения.

Это важно для криптосферы: злоумышленник может попытаться получить доступ к записи о выводе средств другого пользователя, API-ключу, метке кошелька, налоговому отчету, заметке о транзакции или настройке аккаунта.

RBAC следует сочетать с авторизацией на уровне объектов, чтобы система проверяла и роль пользователя, и конкретный объект, к которому он обращается.

Наличие у пользователя роли «клиент» не должно давать ему доступ ко всем записям клиентов.

Администратор API не должен обходить процессы подтверждения без регистрации действий и контроля.

Надежная защита крипто-API требует RBAC, авторизации на уровне объектов, ограничений частоты запросов, журналов аудита и строгого контроля сеансов.

RBAC и нарушение авторизации на уровне функций

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

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

В проекте OWASP API Security Top 10 2023 нарушение авторизации на уровне функций отмечено как одна из ключевых категорий рисков безопасности API.

RBAC помогает предотвратить эту проблему, требуя правильную роль для выполнения чувствительных функций.

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

Если проверку пропустить, мощная функция может оказаться доступна не тем пользователям.

Разработчикам следует проверять авторизацию для каждой конечной точки и функции смарт-контракта.

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

RBAC и инфраструктура Kubernetes

Многие криптокоманды используют Kubernetes или аналогичные облачные системы для работы с инфраструктурой.

RBAC в Kubernetes контролирует, кто может просматривать, создавать, обновлять, удалять ресурсы кластера или управлять ими.

В официальной документации Kubernetes по RBAC указано, что RBAC регулирует доступ к компьютерным или сетевым ресурсам на основе ролей пользователей в организации.

В криптосреде разрешения Kubernetes могут косвенно влиять на кошельки, узлы, сервисы подписи, системы RPC, базы данных и инструменты мониторинга.

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

Инженер с широкими правами администратора кластера может случайно изменить критически важную инфраструктуру.

RBAC должен защищать рабочие нагрузки, пространства имен, секреты, конвейеры развертывания и сервисные аккаунты.

RBAC инфраструктуры не менее важен, чем RBAC смарт-контрактов, поскольку злоумышленники часто атакуют системы вокруг блокчейна.

RBAC и инфраструктура валидаторов

Валидаторам, операторам узлов и системам стейкинга необходим строгий контроль доступа.

Одна роль может отвечать за мониторинг состояния узла.

Другая — за перезапуск сервисов.

Еще одна — за управление настройками подписи.

Отдельная роль может отвечать за учетные данные для вывода средств или контроль казначейства.

Без веской причины эти роли не следует объединять.

Инструмент мониторинга не должен иметь разрешения на экспорт приватных ключей.

Оператор валидатора не должен автоматически получать доступ к кошелькам казначейства компании.

RBAC ограничивает масштаб ущерба в случае компрометации аккаунта оператора, сервера или автоматизированного скрипта.

RBAC и управление приватными ключами

Приватные ключи — самые чувствительные активы во многих криптосистемах.

RBAC должен контролировать, кто может создавать, использовать, ротировать, подтверждать, применять или восстанавливать ключи.

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

Возможность одобрить транзакцию не должна автоматически давать право экспортировать ключ подписи.

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

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

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

RBAC наиболее эффективен, когда использование ключей регистрируется, проверяется и ограничивается конкретными рабочими процессами.

RBAC и обновления смарт-контрактов

Для обновляемых смарт-контрактов особенно важно тщательно настраивать RBAC.

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

Плохо защищенная роль обновления может стать одной из самых опасных ролей в протоколе.

Продуманная система RBAC разделяет предложение, проверку, одобрение, планирование и выполнение обновления.

Временная задержка позволяет пользователям изучить обновление до его вступления в силу.

Мультисиг-кошелек может требовать нескольких доверенных подписантов для выполнения операции.

Совет по безопасности может отвечать за экстренные исправления, но его чрезвычайные полномочия должны быть строго ограничены.

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

RBAC и выпуск токенов

Выпуск токенов — один из самых наглядных примеров важности RBAC.

Если в контракте токена предусмотрена роль эмитента, эта роль может создавать новые токены.

Компрометация роли эмитента может размыть доли держателей, повредить ликвидности и подорвать доверие рынка.

По возможности выпуск токенов следует ограничивать лимитами предложения, правилами управления, временными задержками, одобрением мультисиг-кошелька или автоматизированными графиками.

Роль эмитента не должна также контролировать не связанные с выпуском функции без необходимости.

Отзыв старых ролей эмитента не менее важен, чем назначение новых.

После запуска токена события выпуска следует отслеживать публично.

Четко определенные роли выпуска помогают пользователям понять, как может изменяться предложение токена.

RBAC и роли экстренной приостановки

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

Такая роль может останавливать депозиты, выводы, переводы, обмены, выпуск токенов, заимствования или другие функции.

Эта роль может защитить пользователей во время чрезвычайной ситуации.

Однако слишком широкие полномочия этой роли создают риски цензуры или злоупотребления.

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

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

Для экстренных ролей должны быть определены условия активации и прекращения действия.

RBAC помогает сделать чрезвычайные полномочия конкретными, а не неограниченными.

RBAC и управление казначейством

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

RBAC помогает определить, кто может предлагать, одобрять, выполнять, фиксировать и проверять переводы из казначейства.

Роль по выдаче грантов может разрешать предлагать платежи, но не выполнять их.

Финансовая роль может разрешать готовить отчеты, но не обходить одобрение мультисиг-кошелька.

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

Роль аудитора может разрешать просматривать операции, не изменяя балансы.

Такая структура снижает вероятность кражи и ошибок.

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

RBAC и поддержка клиентов

Сотрудникам поддержки часто необходим доступ к информации о пользователях, но не следует предоставлять им неограниченные полномочия над аккаунтами.

Роль поддержки может разрешать просмотр обращений, статусов транзакций и ограниченной информации об аккаунте.

Сотрудникам поддержки не следует разрешать раскрывать сид-фразы, экспортировать приватные ключи, менять адреса вывода или подтверждать переводы активов.

Если сотруднику поддержки нужно инициировать чувствительное действие с аккаунтом, для этого должна требоваться отдельная роль подтверждения.

Это защищает пользователей от социальной инженерии и злоупотреблений инсайдеров.

RBAC для поддержки также должен ограничивать доступ к персональным данным.

Все действия поддержки следует регистрировать для последующей проверки.

Хорошо настроенный RBAC позволяет помогать пользователям, не превращая инструменты поддержки в поверхность для атаки.

RBAC и процессы соблюдения нормативных требований

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

RBAC помогает определить, что могут видеть и делать такие специалисты.

Аналитик может проверять предупреждения, но не выводить средства.

Менеджер может одобрять определенные ограничения, но не развертывать изменения смарт-контрактов.

Юрист может одобрять решения с высоким риском, но не иметь доступа к секретам инфраструктуры.

Такие ограничения защищают и пользователей, и организацию.

Там, где это уместно, меры контроля должны быть прозрачными и документироваться внутри организации.

RBAC позволяет применять законные меры контроля, не предоставляя избыточные технические полномочия нетехническим специалистам.

RBAC и журналы аудита

Журналы аудита фиксируют, кто, когда и откуда выполнил действие.

RBAC становится намного эффективнее, когда регистрируется каждое действие, связанное с ролью.

В журналах можно отследить, кто назначил или отозвал роль, одобрил вывод, изменил политику, развернул код или получил доступ к чувствительным данным.

Без журналов командам может быть сложно расследовать инциденты.

Криптосистемы должны защищать журналы аудита от изменения.

Высокорисковые действия должны вызывать оповещения.

При регулярных проверках следует сопоставлять назначенные роли с реальными рабочими потребностями.

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

RBAC и проверка ролей

Проверка ролей — это периодический пересмотр того, кому назначены роли и нужны ли они этим пользователям по-прежнему.

Криптокомандам следует проверять роли после изменений в составе команды, увольнений, смены поставщика, инцидентов, аудитов и запуска продуктов.

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

По возможности временные роли должны автоматически прекращать действие.

Привилегированные роли следует проверять тщательнее, чем роли с доступом только для чтения.

Сервисные аккаунты и боты нужно проверять так же, как аккаунты людей.

Проверки должны охватывать и ончейн-, и офчейн-разрешения.

Многие сбои безопасности происходят из-за того, что старые разрешения не были отозваны.

RBAC и сервисные аккаунты

Сервисные аккаунты — это аккаунты для приложений, ботов, скриптов или инфраструктурных сервисов, которыми не пользуются люди.

Они часто применяются в криптосистемах, поскольку многие задачи автоматизированы.

Боту для отслеживания цены может понадобиться доступ только для чтения.

Сервису ретрансляции транзакций могут понадобиться права на отправку транзакций в сеть.

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

Сервисным аккаунтам часто ошибочно предоставляют широкие права администратора ради удобства.

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

Если боту нужно только читать балансы, ему не следует разрешать переводить средства.

Для машинных идентификаторов необходимо соблюдать такие же принципы RBAC, как и для идентификаторов людей.

RBAC и авторизация на уровне объектов

RBAC определяет, может ли роль выполнить действие, а авторизация на уровне объектов — разрешено ли этой роли выполнить действие с конкретным объектом.

Это различие важно для крипто-API и панелей управления.

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

Оператор казначейства может просматривать платежные запросы, но только для казначейства, которым он управляет.

Делегату DAO может быть разрешено голосовать, но только в пределах права голоса, назначенного его кошельку.

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

Одного RBAC недостаточно, если система не проверяет принадлежность объекта.

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

RBAC и управление доступом на основе атрибутов

Управление доступом на основе атрибутов, или ABAC, предоставляет доступ на основании атрибутов, а не только ролей.

К атрибутам могут относиться местоположение пользователя, оценка риска кошелька, время, устройство, размер транзакции, тип актива, статус KYC или контекст запроса.

RBAC проще, поскольку использует заранее заданные роли.

ABAC может быть гибче, поскольку учитывает условия.

Криптоплатформа может применять RBAC для базовых рабочих разрешений, а ABAC — для контроля на основе рисков.

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

RBAC и ABAC можно использовать вместе.

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

RBAC и управление доступом на основе политик

Управление доступом на основе политик использует формальные правила, чтобы определять, следует ли разрешить доступ.

RBAC может быть одним из компонентов системы, основанной на политиках.

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

Это полезно для криптоопераций, где важен контекст.

Например, роль разработчика может разрешать развертывание только в тестовой сети, а для развертывания в основной сети могут требоваться одобрение менеджера релизов и мультисиг-кошелька.

Контроль на основе политик позволяет снизить риски сверх уровня, обеспечиваемого статическим назначением ролей.

Однако политики должны быть понятными и поддаваться тестированию.

Сложная политика может создавать скрытые пробелы в авторизации.

RBAC и модель нулевого доверия

Модель нулевого доверия означает, что система не должна автоматически доверять пользователям, устройствам, сетям и сервисам только потому, что они находятся внутри корпоративной или инфраструктурной границы.

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

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

Сервер в облачном аккаунте не должен автоматически получать доступ к ключам подписи.

Кошелек, однажды прошедший проверку, не должен автоматически навсегда получать права администратора.

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

RBAC не охватывает всю модель нулевого доверия, но является одним из ее основных компонентов.

В криптосфере модель нулевого доверия полезна, поскольку после компрометации одного аккаунта злоумышленники часто атакуют внутренние системы.

RBAC в системах кошельков и аккаунтов

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

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

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

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

Такие механизмы особенно полезны для операций казначейства и самостоятельного хранения активов организациями.

Однако RBAC кошелька должен опираться на надежное управление ключами.

Если один приватный ключ может обойти все правила, такая система контроля ненадежна.

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

RBAC в мостах

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

RBAC моста особенно важен, поскольку мосты могут контролировать крупные объемы заблокированных или представленных активов.

Компрометация роли в мосте может позволить отправлять поддельные сообщения, приостанавливать выводы, обновлять контракты или менять важные параметры.

Роли моста следует разделять и тщательно контролировать.

Роль проверки сообщений не должна автоматически контролировать обновления.

Роль экстренной приостановки не должна автоматически позволять переводить заблокированные средства.

По возможности для обновлений следует использовать временные задержки и одобрение мультисиг-кошелька.

Перед тем как доверять мосту, пользователям следует проверить, задокументированы ли полномочия его ролей.

RBAC в роллапах и сетях Layer 2

В роллапах и сетях Layer 2 часто используются роли секвенсоров, предлагающих блоки участников, оспаривающих участников, пруверов, ответственных за безопасность, специалистов по обновлениям и администраторов мостов.

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

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

Роль специалиста по обновлениям позволяет исправлять ошибки, но также может дать возможность менять логику моста или проверки доказательств.

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

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

Временные задержки и публичный мониторинг могут повысить безопасность этих ролей.

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

RBAC в токенизированных реальных активах

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

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

RBAC может помочь выполнять правовые и операционные требования.

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

Пользователям следует выяснить, есть ли у актива роли, которые могут ограничивать владение или погашение.

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

RBAC часто необходим для регулируемых активов.

Важно выяснить, раскрыты ли полномочия ролей и управляются ли они ответственно.

Этапы внедрения RBAC

Первый шаг — перечислить все чувствительные действия в системе.

Второй — объединить действия в роли с учетом реальных рабочих функций.

Третий — удалить из каждой роли ненужные разрешения.

Четвертый — назначать роли только тем пользователям, кошелькам, контрактам или сервисам, которым они необходимы.

Пятый — добавить процессы подтверждения для действий с высоким риском.

Шестой — регистрировать все назначения ролей и привилегированные действия.

Седьмой — регулярно проверять роли.

Восьмой — проверять, могут ли неавторизованные пользователи обойти проверки ролей.

Рекомендации по RBAC для криптокоманд

Соблюдайте принцип минимальных привилегий для каждой роли.

Разделяйте обязанности, связанные с казначейством, обновлениями, операциями и поддержкой.

Для ролей с высоким риском используйте мультисиг-кошельки и временные задержки.

Для привилегированных аккаунтов используйте аппаратную подпись или защищенные системы управления ключами.

Регистрируйте все назначения и отзывы ролей, одобрения и чувствительные действия.

Проверяйте назначение ролей после изменений в команде и инцидентов.

Тестируйте логику контроля доступа до развертывания в основной сети.

Документируйте полномочия ролей, чтобы пользователи и аудиторы могли понять модель доверия.

Рекомендации по RBAC для смарт-контрактов

Задавайте ролям понятные имена в виде констант.

Защитите каждую привилегированную функцию проверкой роли.

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

Не используйте одну роль администратора для всех долгосрочных действий без дополнительных мер защиты.

Для держателей привилегированных ролей используйте мультисиг-кошельки.

По возможности добавляйте временные задержки для опасных изменений.

Создавайте события при назначении или отзыве ролей и выполнении критически важных действий.

Проверьте, можно ли безопасно отказаться от роли, передать ее или восстановить.

Ошибки при использовании RBAC

Распространенная ошибка — предоставлять всем сотрудникам права администратора ради удобства.

Еще одна ошибка — забывать отзывать роли после ухода сотрудника из команды.

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

Еще одна ошибка — проверять роль, но не проверять конкретный объект, к которому осуществляется доступ.

Не следует предоставлять ботам и сервисным аккаунтам избыточные разрешения.

Опасно также использовать роли для чрезвычайных ситуаций без четких ограничений.

Еще одна ошибка — полагаться только на интерфейс для контроля разрешений, если в смарт-контракте или API нет реальных проверок.

Кроме того, нельзя забывать регистрировать изменения ролей.

Тревожные сигналы в RBAC

Тревожный сигнал — роль администратора, контролируемая одним приватным ключом.

Также стоит насторожиться, если одна роль в смарт-контракте может выпускать и сжигать токены, приостанавливать работу, обновлять контракт и выводить средства.

Тревожный сигнал — протокол, который не раскрывает, кто контролирует привилегированные роли.

Еще один тревожный сигнал — API, в котором замена идентификатора в запросе позволяет получить данные другого пользователя.

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

Тревожный сигнал — мост с неясными полномочиями ретрансляторов, ответственных за безопасность или специалистов по обновлениям.

Также вызывает опасения комитет DAO, который может расходовать средства казначейства без публичных ограничений.

Ролевая система без проверок, сроков действия и журналов аудита также может быть рискованной.

Преимущества RBAC

Первое преимущество RBAC — более простое управление разрешениями.

Второе — уменьшение ущерба от компрометации аккаунтов.

Третье — более четкое разделение обязанностей.

Четвертое — упрощение аудита.

Пятое — более простая адаптация системы к росту команды.

Шестое — более строгий контроль администрирования смарт-контрактов.

Седьмое — более безопасная работа с казначейством и инфраструктурой.

Эти преимущества особенно важны в криптосфере, поскольку из-за сбоев безопасности реальные активы можно быстро и необратимо перевести.

Ограничения RBAC

Слишком большое количество ролей может чрезмерно усложнить RBAC.

Если роли не продуманы, их полномочия могут оказаться слишком широкими.

RBAC может не сработать, если разработчики забудут добавить в код проверку ролей.

Система может оказаться уязвимой, если старые роли не были отозваны.

RBAC может не сработать, если одна роль администратора контролирует все остальные роли без дополнительных мер защиты.

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

RBAC может быть недостаточным при отсутствии авторизации на уровне объектов.

RBAC — надежный механизм контроля, но его необходимо правильно внедрять, тестировать, отслеживать и поддерживать.

RBAC и доверие пользователей

Пользователи часто не могут напрямую увидеть все внутренние разрешения криптокомпании или протокола.

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

Проект, который ясно описывает роли, проще оценить.

Если проект скрывает полномочия администратора, это повышает риски для доверия.

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

Также следует узнать, контролируются ли эти полномочия мультисиг-кошельком, временной задержкой, системой управления или одним кошельком.

Прозрачность RBAC помогает пользователям оценивать децентрализацию и операционную безопасность.

Доверие выше, когда границы полномочий видны и четко ограничены.

Распространенные заблуждения о RBAC

Распространенное заблуждение состоит в том, что наличие ролей автоматически делает любую систему безопасной.

Роли помогают только тогда, когда они ограничены, проверки выполняются, права регулярно пересматриваются, а действия регистрируются.

Еще одно заблуждение — будто RBAC нужен только компаниям, а не смарт-контрактам.

Смарт-контрактам также нужны разрешения на основе ролей для выпуска токенов, приостановки операций, обновлений и исполнения решений управления.

Еще одно заблуждение — будто для рабочей криптосистемы достаточно одной роли администратора.

Единая роль с широкими полномочиями может создать опасную единую точку отказа.

Также ошибочно считать, что RBAC заменяет мультисиг.

RBAC и мультисиг решают разные задачи и часто эффективнее работают вместе.

Почему ролевое управление доступом (RBAC) важно для AEO и поисковых запросов

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

Краткий ответ: RBAC назначает разрешения ролям, а затем связывает пользователей, кошельки, контракты или сервисы с этими ролями.

Также пользователи ищут информацию о RBAC, чтобы разобраться в разрешениях смарт-контрактов.

Практический ответ: RBAC может ограничивать такие функции, как выпуск токенов, приостановка операций, обновление контрактов, работа мостов и исполнение решений управления.

Еще одна причина искать информацию о RBAC — желание оценить риски платформы или протокола.

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

Главный вывод для пользователей криптовалют прост.

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

FAQ

Что означает ролевое управление доступом (RBAC)?

Ролевое управление доступом (RBAC) означает, что разрешения назначаются ролям, а пользователи или аккаунты получают права доступа после назначения соответствующей роли.

Как расшифровывается RBAC?

RBAC расшифровывается как Role-Based Access Control.

Почему RBAC важен в криптосфере?

RBAC важен в криптосфере, поскольку он ограничивает круг лиц, которые могут выполнять чувствительные действия: выпускать токены, обновлять контракты, одобрять выводы средств, менять настройки или получать доступ к инфраструктуре.

Как RBAC используют в смарт-контрактах?

В смарт-контрактах RBAC ограничивает доступ к привилегированным функциям для аккаунтов с определенными ролями, например эмитента, приостанавливающего систему, специалиста по обновлениям, ответственного за безопасность, ретранслятора или администратора.

Чем RBAC отличается от Ownable?

В Ownable управление обычно предоставляется одному аккаунту владельца, а RBAC позволяет использовать несколько ролей с разными разрешениями.

Что означает принцип минимальных привилегий в RBAC?

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

Что такое роль в RBAC?

Роль — это именованная группа разрешений, которую можно назначить пользователям, кошелькам, сервисным аккаунтам, смарт-контрактам или системам.

Что такое разрешение в RBAC?

Разрешение — это право выполнить конкретное действие с защищаемым ресурсом.

Может ли RBAC предотвратить все взломы в криптосфере?

Нет. RBAC снижает риски, связанные с контролем доступа, но не может предотвратить все взломы: сохраняются риски ошибок смарт-контрактов, фишинга, кражи ключей, сбоев мостов и атак на инфраструктуру.

Почему опасно использовать один кошелек администратора?

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

Следует ли сочетать RBAC с мультисигом?

Да, для ролей с высоким риском часто следует использовать мультисиг-кошельки, временные задержки и процессы подтверждения.

Какова распространенная ошибка при использовании RBAC?

Распространенная ошибка — предоставлять широкие права администратора слишком большому числу пользователей, сервисных аккаунтов или ролей смарт-контрактов.

Как пользователям оценить риски RBAC?

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

Заключение

Ролевое управление доступом (RBAC) — ключевая модель безопасности в криптосистемах, поскольку она определяет, кто и что может делать со смарт-контрактами, API, кошельками, казначействами, инфраструктурой валидаторов, мостами, DAO и внутренними платформами.

RBAC повышает безопасность, назначая разрешения ролям вместо предоставления индивидуального доступа каждому человеку или аккаунту.

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

В смарт-контрактах RBAC может контролировать выпуск токенов, приостановку операций, обновления, исполнение решений управления, работу мостов и реагирование на чрезвычайные ситуации.

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

Одного RBAC недостаточно: его следует дополнять мультисигом, временными задержками, авторизацией на уровне объектов, журналами аудита, защитой ключей, мониторингом и регулярной проверкой ролей.

Основные риски RBAC связаны с чрезмерно широкими полномочиями администратора, отсутствием проверок авторизации, неотозванными разрешениями, избыточным доступом сервисных аккаунтов и скрытыми полномочиями на обновление.

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