ロールベースアクセス制御（RBAC）

暗号資産におけるロールベースアクセス制御（RBAC）とは？

ロールベースアクセス制御（RBAC）は、個々のユーザー、ウォレット、サービスアカウント、スマートコントラクト、オペレーターに権限を一つずつ直接付与するのではなく、役割（ロール）に権限を割り当てるセキュリティモデルです。

暗号資産の分野では、トークンのミント、コントラクトの一時停止、トレジャリーの管理、出金の承認、アップグレードのデプロイ、ダッシュボードへのアクセス、鍵のローテーション、バリデーターの運用、プロトコル設定の変更を誰が行えるか定義するうえで、RBACが役立ちます。

NISTのRBAC用語集では、RBACは、リソースに対して許可される操作を個々の主体の識別情報ではなく、役割に基づいて定めるモデルと定義されています。

つまり、暗号資産システムでは、Admin、Treasury Manager、Smart Contract Upgrader、Validator Operator、Risk Reviewer、Support Agent、Auditor、Read-Only Analystなどの役割を設定できます。

各役割には、その業務に必要な権限のみが付与されます。

その後、ユーザー、ウォレット、ボット、サーバー、コントラクトを各役割に割り当てます。

暗号資産システムが取り扱うのは、取り消しが困難なトランザクション、価値の高い秘密鍵、オンチェーンのトレジャリー、ユーザー残高、トークン供給量、機密性の高いインフラなどであるため、RBACは重要です。

アクセス制御の設計が不十分だと、パスワードの漏えい、APIキーの侵害、悪意ある内部関係者の存在、管理者ウォレットの盗難が、システム全体の障害につながるおそれがあります。

ロールベースアクセス制御（RBAC）の簡単な定義

ロールベースアクセス制御（RBAC）とは、あらかじめ定められたアクセス権を持つ役割にユーザーやアカウントを割り当て、権限を管理する方法です。

個々のユーザーに何ができるかを一つずつ問うのではなく、そのユーザーの役割で何が許可されているかを確認します。

たとえば、トレジャリーの署名者には支払いの承認を許可し、スマートコントラクトのアップグレードのデプロイは許可しない、といった設定が可能です。

スマートコントラクトのアップグレード担当者にはアップグレードのスケジュール設定を許可し、トレジャリー資金の移動は許可しない設定にできます。

サポート担当者にはアカウント状況の閲覧を許可し、出金設定の変更は許可しないようにできます。

バリデーターの運用担当者にはインフラの再起動を許可し、トレジャリーの秘密鍵へのアクセスは許可しない設定にできます。

このように権限を分離することで、1つのアカウントが侵害された場合に生じる被害を抑えられます。

RBACの基本的な考え方はシンプルです。各役割に必要最小限の権限を付与し、その役割を本当に必要とする人やシステムにのみ割り当てます。

暗号資産においてRBACが重要な理由

ブロックチェーン上の操作には取り消しが困難な高額の取引が伴うことが多いため、暗号資産の分野ではRBACが重要です。

誤ったアカウントがトークンのミント、コントラクトのアップグレード、手数料の変更、出金の一時停止、資金の移動を行えると、ユーザーが大きな損失を被る可能性があります。

暗号資産プロジェクトは、API、クラウドサーバー、データベース、コンプライアンスツール、カスタマーサポート用ダッシュボード、署名サービス、監視システム、デプロイパイプラインなど、ブロックチェーン外の多くのシステムにも依存しています。

これらのシステムのすべてに、厳格な権限管理が必要です。

RBACを導入すると、プロジェクトに関わるすべてのメンバーに広範な管理者権限を付与せずに済みます。

また、機密性の高い操作を行う権限が誰にあったのかを証明しやすくなります。

ユーザーにとって、強固なRBACは、従業員、開発者、サービスアカウントが1つ侵害されただけでプラットフォームやプロトコル全体に被害が及ぶ可能性を低減します。

開発者にとって、RBACは基本的な運用セキュリティ、スマートコントラクトの安全性、信頼管理の一部です。

RBACの仕組み

RBACは、保護が必要なリソースを特定することから始まります。

暗号資産分野で保護対象となるリソースには、スマートコントラクトの関数、トレジャリーウォレット、APIエンドポイント、バリデーターノード、管理者用ダッシュボード、クラウドクラスター、顧客データ、署名鍵、ブリッジの制御機能、デプロイスクリプトなどがあります。

次に、これらのリソースに対して実行できる操作を定義します。

操作には、読み取り、書き込み、承認、権限の取り消し、ミント、バーン、一時停止、アップグレード、出金、デプロイ、ローテーション、署名、設定などがあります。

次に、それらの操作を役割ごとにまとめます。

最後に、ユーザー、ウォレット、サービスアカウント、コントラクトを役割に割り当てます。

誰かが操作を実行しようとすると、システムはその主体が必要な役割を持っているか確認します。

その役割に必要な権限があれば操作は許可され、権限がなければ拒否されます。

RBACの主な構成要素

RBACの主な構成要素は、主体、役割、権限、リソース、セッション、ポリシーです。

主体とは、アクセスを要求する個人、ウォレット、ボット、サービスアカウント、スマートコントラクト、バリデーターのプロセス、サーバーなどを指します。

役割とは、権限をまとめた名前付きのグループです。

権限とは、リソースに対して許可された操作です。

リソースとは、保護の対象となるものです。

セッションとは、主体が1つ以上の役割を有効に使用している状態です。

ポリシーとは、役割の作成、割り当て、見直し、削除の方法を定めたルールです。

これらの構成要素を適切に設計すれば、RBACによってアクセス制御の管理と監査が容易になります。

スマートコントラクトにおけるRBAC

スマートコントラクトでは、特権機能を制御するためにRBACが広く利用されています。

たとえば、トークンコントラクトに新しいトークンを発行できるminterロールを設定できます。

ガバナンスコントラクトには、承認済みの提案を実行できるexecutorロールを設定できます。

ブリッジコントラクトには、検証済みメッセージを送信できるrelayerロールを設定できます。

DeFiプロトコルには、緊急時にリスクの高い機能を一時停止できるguardianロールを設定できます。

OpenZeppelinのスマートコントラクトのアクセス制御に関するドキュメントでは、アクセス制御は「誰が何を実行できるか」に答えるものであり、トークンのミント、投票、送金の凍結などを管理できると説明されています。

OpenZeppelinのAccessControl APIドキュメントでは、コントラクトごとのロールベースのアクセス制御メカニズムについて説明されています。この仕組みでは、階層構造を持つ複数の役割を作成し、複数のアカウントに割り当てることができます。

そのため、RBACは本番環境のスマートコントラクトにおける重要な設計パターンです。

RBACとOwnableスマートコントラクトの違い

Ownableは、1つのオーナーアカウントに管理者権限を付与するシンプルなアクセス制御パターンです。

RBACは、権限ごとに異なる役割を設定できるため、より柔軟です。

簡単なテストや非常に小規模なコントラクトであれば、Ownableでも十分な場合があります。

本番環境の暗号資産システムでは、1つのアカウントがすべての機密性の高い操作を管理すべきではないため、オーナー1人による管理では不十分になることが少なくありません。

たとえば、プロトコルを一時停止するアカウントが、自動的にトークンのミントやトレジャリー資金の出金まで行えるべきではありません。

コントラクトをアップグレードするアカウントが、自動的にリスクパラメーターまで変更できるべきではありません。

RBACは職務の分離を可能にします。

この分離により、1つの鍵の侵害がプロトコル全体の侵害につながる可能性を低減できます。

RBACと最小権限の原則

最小権限の原則とは、ユーザー、サービス、ウォレット、プロセスに対し、その業務に必要な権限のみを付与することです。

RBACは、最小権限の原則を実践するうえで最も実用的な方法の一つです。

KubernetesのRBACに関するベストプラクティスでは、ユーザーとサービスアカウントに最小限の権限を割り当て、運用に明示的に必要な権限のみを使用することが推奨されています。

暗号資産の分野では、不要なアクセス権が壊滅的な結果を招くおそれがあるため、この原則は非常に重要です。

読み取りアクセスだけが必要な開発者に、資金を移動する権限を与えるべきではありません。

監視ボットにコントラクトの所有権を変更する権限を与えるべきではありません。

サポート担当者に出金保護を無効化する権限を与えるべきではありません。

最小権限の原則を適用することで、RBACは単なる権限一覧ではなく、実効性のあるセキュリティ対策となります。

RBACと職務の分離

職務の分離とは、危険性の高いプロセスを1つの役割だけで完了できないようにすることです。

たとえば、ある役割が出金申請を作成し、別の役割が審査し、マルチシグが承認する運用にできます。

ある役割がスマートコントラクトのアップグレードを提案し、別の役割が監査し、さらに別の役割がタイムロック後に実行する方法もあります。

この仕組みにより、内部関係者によるリスクとアカウント侵害のリスクを低減できます。

また、複数の独立した役割の協力が必要になるため、不正行為が困難になります。

暗号資産の分野では、職務の分離はトレジャリー管理、ブリッジ運用、バリデーター管理、リリースへの署名、トークンのミント、緊急対応に役立ちます。

RBACを使えば、権限を明確に定義された役割に分けることで、こうした運用を実現できます。

強固な暗号資産運用では、資金、コード、インフラを同時に無制限に管理できる役割を設けません。

RBACとマルチシグウォレット

マルチシグウォレットでは、トランザクションを実行する前に複数の承認が必要です。

RBACとマルチシグウォレットは相性がよいものの、同じ仕組みではありません。

RBACは、誰がどの権限を持つかを決定します。

マルチシグは、トランザクションを送信する前に何人の承認済み署名者が同意する必要があるかを決定します。

トレジャリーの役割に支払い申請の作成が許可されていても、マルチシグで複数の署名者による承認が必要になる場合があります。

プロトコル管理者の役割でアップグレードをスケジュールできても、タイムロックとマルチシグによって最終的な実行が遅延され、承認される場合があります。

この組み合わせにより、どちらか一方だけを使う場合よりも強固な管理体制を構築できます。

価値の高い暗号資産システムでは、通常、RBACをマルチシグ、タイムロック、監視、明確なガバナンスルールと併用する必要があります。

RBACとDAO

DAOはRBACを使って権限委譲を管理できます。

DAOでは、トレジャリー委員会、助成金審査担当者、セキュリティ評議会、プロトコルガーディアン、コミュニティモデレーター、技術メンテナーなどの役割を設定できます。

こうした役割があれば、小さな作業のたびにコミュニティ全体で投票するよりも迅速に対応できます。

ただし、委譲された役割の権限は限定され、透明性が確保されていなければなりません。

DAOの役割には、明確な権限範囲、有効期限、説明責任のプロセス、権限を取り消す方法を定める必要があります。

委員会が十分な監督なしに資金を移動したりコントラクトをアップグレードしたりできる場合、そのDAOは名目上だけの分散型組織になるおそれがあります。

RBACはDAOの運営に役立つ一方、役割の権限が広すぎると、中央集権化を覆い隠すことにもなり得ます。

適切なDAOのRBACでは、誰にどの権限があるのかがトークン保有者やユーザーに見えるようにする必要があります。

暗号資産プラットフォームにおけるRBAC

暗号資産プラットフォームでは、多くの従業員やサービスが機密性の高い業務に関わるため、社内システム全体でRBACが必要です。

役割には、コンプライアンスアナリスト、出金審査担当者、ウォレット運用担当者、トレジャリーマネージャー、カスタマーサポート、エンジニア、インシデント対応担当者、監査担当者、システム管理者などがあります。

各役割には、業務に必要なアクセス権のみを付与する必要があります。

サポート担当者には問い合わせ状況の閲覧を許可しても、高額出金の承認は許可すべきではありません。

エンジニアにはステージング環境へのコードのデプロイを許可しても、本番環境の署名鍵へのアクセスは許可すべきではありません。

トレジャリー運用担当者には送金の準備を許可しても、単独での実行は許可すべきではありません。

RBACは内部脅威や運用ミスの低減に役立ちます。

また、どの役割がどの操作を行ったかをプラットフォームが示せるため、監査可能性も向上します。

RBACとAPIセキュリティ

暗号資産サービスでは、ウォレット、取引ツール、ダッシュボード、カストディシステム、レポート、アカウント管理にAPIが広く使われています。

認証だけでは、ユーザーが要求した操作を実行する権限を持っているとは確認できないため、APIにおいてRBACは重要です。

OWASPのAPI1:2023 Broken Object Level Authorizationに関するガイダンスでは、エンドポイントが権限を適切に確認しない場合、攻撃者がオブジェクトIDを操作してAPIを悪用する可能性があると説明されています。

暗号資産の分野では、攻撃者が他のユーザーの出金記録、APIキー、ウォレットのラベル、税務レポート、トランザクションメモ、アカウント設定などにアクセスしようとする可能性があるため、これは重要です。

RBACはオブジェクトレベルの認可と組み合わせ、システムがユーザーの役割とアクセス対象の個別オブジェクトの両方を確認するようにする必要があります。

「顧客」という役割を持つユーザーが、すべての顧客記録を閲覧できるようにしてはいけません。

API管理者が、ログや監督なしに承認ワークフローを回避できるようにしてはいけません。

強固な暗号資産APIセキュリティには、RBAC、オブジェクトレベルの認可、レート制限、監査ログ、厳格なセッション管理が必要です。

RBACと関数レベルの認可不備

関数レベルの認可不備とは、本来は許可されていない関数をユーザーが呼び出せる状態です。

暗号資産の分野では、一般ユーザーが管理者用エンドポイント、出金の上書きツール、トークン上場の管理機能、内部ウォレット機能にアクセスできるケースなどが考えられます。

OWASPのAPI Security Top 10 2023プロジェクトでは、関数レベルの認可不備が主要なAPIセキュリティ上の問題として挙げられています。

RBACを導入すると、機密性の高い関数の実行前に適切な役割を要求することで、この問題を防ぎやすくなります。

ただし、機密性の高い関数すべてで権限が確認されなければ、RBACは機能しません。

権限チェックを1つ忘れただけでも、強力な機能が不適切なユーザーに公開されるおそれがあります。

開発者は、すべてのエンドポイントとスマートコントラクト関数で認可をテストする必要があります。

セキュリティレビューでは、認可チェックの欠落を重大な問題として扱う必要があります。

KubernetesインフラにおけるRBAC

多くの暗号資産チームは、Kubernetesや類似のクラウドシステム上でインフラを運用しています。

Kubernetes RBACは、クラスターリソースの読み取り、作成、更新、削除、管理を誰が行えるかを制御します。

公式のKubernetes RBACドキュメントでは、RBACは組織内のユーザーの役割に基づいて、コンピューターやネットワークリソースへのアクセスを制御する仕組みと説明されています。

暗号資産環境では、Kubernetesの権限がウォレット、ノード、署名サービス、RPCシステム、データベース、監視ツールに間接的な影響を及ぼす可能性があります。

過剰なクラスター権限を持つサービスアカウントは、秘密鍵や本番環境のシークレットへの侵入口になるおそれがあります。

広範なcluster-admin権限を持つエンジニアが、誤って重要なインフラを変更する可能性もあります。

RBACでは、ワークロード、名前空間、シークレット、デプロイパイプライン、サービスアカウントを保護する必要があります。

攻撃者はブロックチェーン周辺のシステムを狙うことが多いため、インフラのRBACはスマートコントラクトのRBACと同じくらい重要です。

バリデーターインフラにおけるRBAC

バリデーター、ノード運用者、ステーキングシステムには、厳格なアクセス制御が必要です。

ある役割にはノードの稼働状況の監視を許可できます。

別の役割にはサービスの再起動を許可できます。

さらに別の役割には署名設定の管理を許可できます。

別の役割には、出金認証情報やトレジャリー関連の制御を担当させることができます。

強い理由がない限り、これらの役割を統合すべきではありません。

監視ツールに秘密鍵をエクスポートする権限を与えるべきではありません。

バリデーターの運用担当者に、事業用トレジャリーウォレットへのアクセスを自動的に許可すべきではありません。

運用者のアカウント、サーバー、自動化スクリプトが侵害された場合、RBACによって被害の範囲を抑えられます。

RBACと秘密鍵の管理

多くの暗号資産システムにおいて、秘密鍵は最も機密性の高い資産です。

RBACでは、鍵の生成、アクセス、ローテーション、承認、使用、復旧を誰が行えるか管理する必要があります。

可能な限り、鍵へのアクセスとトランザクションの承認は分離する必要があります。

トランザクションを承認できる人に、署名鍵をエクスポートする権限まで自動的に与えるべきではありません。

トランザクションに署名するシステムに、ウォレットのポリシーを変更する権限まで自動的に与えるべきではありません。

ハードウェアセキュリティモジュール、マルチシグウォレット、ポリシーエンジン、鍵管理システムは、いずれもRBACに類似した制御をサポートできます。

すべての鍵について、管理者、役割ポリシー、ローテーション手順、緊急時の権限取り消し計画を定める必要があります。

鍵の使用が記録され、レビューされ、特定のワークフローに限定されているとき、RBACは最も強固になります。

RBACとスマートコントラクトのアップグレード

アップグレード可能なスマートコントラクトでは、特に慎重なRBAC設計が必要です。

アップグレードによって、プロトコルのロジック、資産の取り扱い、手数料、権限、出金の動作が変わる可能性があります。

管理が不十分なアップグレード担当者の役割は、プロトコル内で最も危険な役割の一つになり得ます。

適切なアップグレード用RBACでは、提案、レビュー、承認、スケジュール設定、実行を分離します。

タイムロックを設けると、アップグレードが有効になる前にユーザーが内容を確認する時間を確保できます。

マルチシグを使うと、実行前に複数の信頼できる署名者の承認を必要とすることができます。

セキュリティ評議会が緊急パッチを扱う場合もありますが、緊急時の権限範囲は限定する必要があります。

ユーザーは、コントラクトをアップグレードできるのが誰か、変更前に十分な時間をかけて資産を引き出せるかを確認する必要があります。

RBACとトークンのミント

トークンのミントは、RBACが重要である理由を示す代表的な例です。

トークンコントラクトにminterロールが設定されている場合、その役割によって新しいトークンを発行できます。

minterロールが侵害されると、トークン保有者の持分が希薄化し、流動性が損なわれ、市場の信頼が失われる可能性があります。

可能であれば、供給上限、ガバナンスルール、タイムロック、マルチシグ承認、自動スケジュールなどによってミントを制限する必要があります。

必要がない限り、minterロールに無関係な機能の管理権限も与えるべきではありません。

古いminterロールを取り消すことは、新しいロールを付与することと同じくらい重要です。

トークンが運用中の場合、ミントの実行状況を公開して監視できるようにする必要があります。

ミントに関するRBACを明確にすれば、トークン供給量がどのように変化するのかをユーザーが理解しやすくなります。

RBACと緊急停止ロール

多くの暗号資産プロトコルでは、エクスプロイトや深刻な不具合が発生した際にリスクの高い活動を止めるため、緊急停止ロールを設けています。

停止ロールによって、入金、出金、送金、スワップ、ミント、借入などの機能を停止できる場合があります。

この役割は、緊急時にユーザーを保護するのに役立ちます。

一方、権限範囲が広すぎると、検閲や権限の悪用につながるリスクもあります。

適切な停止ロールは、権限範囲を限定し、内容を文書化し、監視下に置き、信頼できるプロセスで管理する必要があります。

システムがその権限を明確に開示していない限り、資産の盗難や恒久的な凍結をひそかに許可するものであってはなりません。

緊急ロールには、発動と解除の条件を定める必要があります。

RBACを使えば、緊急時の権限を無制限ではなく、特定の範囲に限定できます。

RBACとトレジャリー管理

暗号資産のトレジャリーには、ネイティブコイン、ステーブル資産、ガバナンストークン、NFT、RWAトークン、運用資金などが保管されている場合があります。

RBACを使うと、トレジャリー資産の移動を誰が提案、承認、実行、記録、監査できるかを定義できます。

助成金担当の役割には支払いの提案を許可しても、実行は許可しない設定にできます。

財務担当の役割にはレポートの作成を許可しても、マルチシグ承認の回避は許可しない設定にできます。

トレジャリーの署名者にはトランザクションの承認を許可しても、単独で署名者の構成を変更する権限は与えないようにできます。

監査担当の役割には、資金を変更せずに活動を閲覧する権限を付与できます。

こうした体制により、盗難やミスの可能性を低減できます。

トレジャリーのRBACは、支出上限、トランザクションシミュレーション、送付先アドレスの許可リスト、定期的なレビューと併用する必要があります。

RBACとカスタマーサポート

カスタマーサポートチームにはユーザー情報へのアクセスが必要な場合がありますが、アカウントに対する無制限の権限を与えるべきではありません。

サポート担当の役割には、問い合わせ、トランザクションの状況、限定的なアカウント情報の閲覧を許可できます。

シードフレーズの開示、秘密鍵のエクスポート、出金アドレスの変更、資産移動の承認は許可すべきではありません。

サポート担当者が機密性の高いアカウント操作を開始する必要がある場合、その操作には別の承認役割を必要とするべきです。

これにより、ソーシャルエンジニアリングや内部関係者による不正からユーザーを保護できます。

サポート用RBACでは、個人を特定できる情報へのアクセスも制限する必要があります。

サポートによるすべての操作を記録し、レビューできるようにする必要があります。

適切なRBACは、サポートツールが攻撃対象になることを防ぎながら、ユーザーへの支援を可能にします。

RBACとコンプライアンス業務

コンプライアンスチームは、法的要件に基づいてトランザクションを審査し、ウォレットをスクリーニングし、アラートを調査し、取引を制限する必要がある場合があります。

RBACを使うと、コンプライアンス関連の役割で閲覧や実行が可能な操作を定義できます。

コンプライアンスアナリストにはアラートの審査を許可しても、資金の出金は許可しない設定にできます。

コンプライアンスマネージャーには特定の制限措置の承認を許可しても、スマートコントラクトの変更のデプロイは許可しない設定にできます。

法務担当者にはリスクの高い判断の承認を許可しても、インフラのシークレットへのアクセスは許可しない設定にできます。

こうした制限は、ユーザーと組織の双方を保護します。

コンプライアンス管理は、適切な範囲で透明性を確保し、社内で文書化する必要があります。

RBACは、技術部門以外の役割に不要な技術的権限を与えることなく、法令に沿った管理を支援できます。

RBACと監査ログ

監査ログには、誰が、いつ、どこから、何を行ったかが記録されます。

各役割の操作がすべて記録されると、RBACはより強固になります。

ログには、役割の付与や取り消し、出金の承認、ポリシーの変更、コードのデプロイ、機密データへのアクセスを行った人物を記録できます。

ログがなければ、チームはインシデントを調査できない場合があります。

暗号資産システムでは、監査ログが改ざんされないよう保護する必要があります。

リスクの高い操作ではアラートを発生させる必要があります。

定期的にレビューを行い、割り当てられた役割が実際の業務上の必要性と一致しているか確認する必要があります。

監査ログのないRBACは、誰も確認しない権限管理用の表になってしまうおそれがあります。

RBACと役割の定期レビュー

役割のレビューとは、誰がどの役割を持っているか、その役割が引き続き必要かを定期的に確認することです。

暗号資産チームは、人員の変更、退職、ベンダーの変更、インシデント、監査、製品のローンチ後に役割を見直す必要があります。

担当業務が変わったり、組織を離れたりした人の古い役割は、速やかに削除する必要があります。

可能であれば、一時的な役割は自動的に期限切れとなるようにします。

特権的な役割は、読み取り専用の役割よりも厳格にレビューする必要があります。

サービスアカウントやボットも、人間のユーザーと同様にレビューする必要があります。

レビューでは、オンチェーンとオフチェーンの両方の権限を確認する必要があります。

セキュリティ上の問題の多くは、古いアクセス権が取り消されないことから発生します。

RBACとサービスアカウント

サービスアカウントとは、アプリケーション、ボット、スクリプト、インフラサービスが使用する、人間以外のアカウントです。

多くの処理が自動化されているため、暗号資産システムではサービスアカウントが広く使われています。

価格監視ボットには読み取りアクセスが必要な場合があります。

トランザクション中継サービスにはブロードキャスト権限が必要な場合があります。

デプロイパイプラインには、ステージング環境のコントラクトを更新する権限が必要な場合があります。

利便性を優先してサービスアカウントに広範な管理者権限を付与するのは、危険な誤りです。

サービスアカウントには、限定的な権限、鍵のローテーション、有効期限のルール、ネットワーク制限、監視を設定する必要があります。

残高の読み取りだけが必要なボットに、資金を移動する権限を与えるべきではありません。

機械のIDにも、人間のIDと同じRBACの規律を適用する必要があります。

RBACとオブジェクトレベルの認可

RBACは、ある役割が操作を実行できるかを判断します。一方、オブジェクトレベルの認可は、その役割が特定のオブジェクトに対してその操作を実行できるかを判断します。

この違いは、暗号資産関連のAPIやダッシュボードで重要です。

顧客の役割を持つユーザーはアカウント情報の閲覧を許可されていても、自分自身のアカウント情報だけを閲覧できるようにする必要があります。

トレジャリー運用担当者には支払い申請の閲覧を許可しても、担当するトレジャリーの申請に限定する必要があります。

DAOの代表者には投票を許可しても、そのウォレットに割り当てられた投票権の範囲内に限定する必要があります。

OWASPは、ユーザーから渡されたIDを使ってデータソースにアクセスするすべての関数で、オブジェクトレベルの認可チェックを検討すべきだと警告しています。

オブジェクトの所有者が確認されなければ、RBACだけでは不十分です。

安全なシステムでは、役割の確認とリソースごとの確認を組み合わせます。

RBACと属性ベースアクセス制御

属性ベースアクセス制御（ABAC）は、役割だけではなく属性に基づいてアクセスを許可する仕組みです。

属性には、ユーザーの所在地、ウォレットのリスクスコア、時刻、デバイス、トランザクション額、資産の種類、KYC状況、リクエストのコンテキストなどがあります。

RBACは、あらかじめ定められた役割を使うため、よりシンプルです。

ABACは条件を考慮するため、より柔軟に設定できます。

暗号資産プラットフォームでは、基本的な職務権限にRBACを使い、リスクに応じた制御にABACを使う場合があります。

たとえば、出金審査担当の役割で少額の出金を承認できても、高額の出金では金額とリスクに応じて追加の承認を必要とする設定が可能です。

RBACとABACは併用できます。

最適なアクセス制御モデルは、システムのリスク、複雑さ、監査要件によって異なります。

RBACとポリシーベースアクセス制御

ポリシーベースアクセス制御では、アクセスを許可するかどうかを正式なルールに基づいて判断します。

RBACは、ポリシーベースのシステムを構成する要素の一つになり得ます。

たとえば、ポリシーに「役割を持つユーザーは、営業時間内に、承認済みのデバイスから、上限額以下の出金のみを承認でき、さらに別の役割による審査を経る必要がある」と定めることができます。

これは、状況に応じた判断が重要な暗号資産運用で役立ちます。

たとえば、開発者の役割ではテストネットへのみデプロイでき、本番環境へのデプロイにはリリースマネージャーとマルチシグの承認を必要とする設定が可能です。

ポリシーベースの制御を導入すると、固定的な役割の割り当てだけの場合よりもリスクを低減できます。

ただし、ポリシーは理解しやすく、テスト可能でなければなりません。

分かりにくいポリシーは、認可に隠れた抜け穴を生む可能性があります。

RBACとゼロトラスト

ゼロトラストとは、ユーザー、デバイス、ネットワーク、サービスが会社やインフラの境界内にあるというだけで、自動的に信頼しない考え方です。

RBACは、機密性の高い操作ごとに明示的な権限を要求することで、ゼロトラストを支援します。

社内ネットワークにいる開発者に、本番環境へのアクセスを自動的に許可すべきではありません。

クラウドアカウント内にあるサーバーに、署名鍵へのアクセスを自動的に許可すべきではありません。

一度サインインしたウォレットアドレスに、管理者権限を永続的に付与すべきではありません。

ゼロトラストには、継続的な検証、ログ記録、デバイスの確認、セッション制限、最小権限の原則も必要です。

RBACはゼロトラストモデルのすべてではありませんが、その中核となる要素です。

暗号資産の分野では、1つのアカウントが侵害された後に攻撃者が内部システムを狙うことが多いため、ゼロトラストが役立ちます。

ウォレット・アカウントシステムにおけるRBAC

チームや組織向けの一部のウォレットシステムでは、役割に基づく権限を設定できます。

ある担当者がトランザクションを作成し、別の担当者が承認し、さらに別の担当者には残高の閲覧だけを許可できます。

暗号資産を利用する企業には、1人の従業員が会社資金に対する無制限の権限を持たないようにするため、こうした管理が必要です。

ウォレットのRBACには、支出上限、送付先アドレスの許可リスト、役割に基づく承認、デバイス制限、トランザクションポリシーなどを設定できます。

これらの管理は、トレジャリー運用や機関投資家による自己管理に特に役立ちます。

ただし、ウォレットのRBACは安全な鍵管理によって裏付けられている必要があります。

1つの秘密鍵ですべてのポリシーを回避できるなら、そのポリシーは脆弱です。

強固なウォレットRBACは、ユーザーインターフェースだけでなく、署名の仕組みによって強制される必要があります。

ブリッジにおけるRBAC

暗号資産ブリッジでは、リレイヤー、ガーディアン、バリデーター、アップグレード担当者、一時停止担当者、緊急対応担当者の役割が必要になることがよくあります。

ブリッジは大量のロック済み資産や表現された資産を管理できるため、ブリッジのRBACは非常に機密性が高いものです。

ブリッジの役割が侵害されると、偽のメッセージの送信、出金の一時停止、コントラクトのアップグレード、重要なパラメーターの変更が行われるおそれがあります。

ブリッジの役割は分離し、慎重に監視する必要があります。

メッセージの検証を行う役割に、アップグレードの管理権限まで自動的に与えるべきではありません。

緊急停止ロールに、ロックされた資金を移動する権限まで自動的に与えるべきではありません。

可能であれば、アップグレードの役割にはタイムロックとマルチシグ承認を適用する必要があります。

ブリッジを信頼する前に、ユーザーは役割の権限が公開されているか確認する必要があります。

ロールアップとLayer 2ネットワークにおけるRBAC

ロールアップやLayer 2ネットワークでは、シーケンサー、プロポーザー、チャレンジャー、プルーバー、ガーディアン、アップグレード担当者、ブリッジ管理者などの役割がよく使われます。

これらの役割は、稼働性、検閲耐性、証明の提出、アップグレード、出金に影響します。

中央集権型のシーケンサー役割によってネットワークの処理を高速化できる一方、トランザクションの順序付けに関するリスクが生じる場合があります。

アップグレード担当者の役割はバグ修正に役立つ一方、ブリッジや証明のロジックを変更することも可能です。

ガーディアンの役割は緊急時にシステムを一時停止できる一方、ユーザーの活動を制限することも可能です。

システムを誰が変更できるかをユーザーが把握できるよう、ロールアップのRBACは明確に開示する必要があります。

タイムロックと公開監視によって、これらの役割をより安全に運用できます。

手数料が低いことだけに注目し、権限やアップグレードに関するリスクを見落としてはなりません。

トークン化された現実世界資産におけるRBAC

トークン化された現実世界資産では、発行者、トランスファーエージェント、コンプライアンス審査担当者、カストディアン、監査担当者、償還運用担当者などの役割が必要になることがよくあります。

これらの役割は、ミント、バーン、送金制限、準備金報告、償還承認、ユーザーの適格性を管理する場合があります。

RBACは、法的要件や運用上の要件を適用するのに役立ちます。

一方で、特定の役割が送金を凍結したり、アドレスをブロックしたりできる場合、中央集権化につながる可能性もあります。

ユーザーは、資産に保有権や償還を制限できる役割が設定されているか理解する必要があります。

トークン化資産がオンチェーンであっても、そのアクセス制御はオフチェーンの法的手続きやコンプライアンスプロセスに依存する場合があります。

規制対象資産では、RBACが必要となることが少なくありません。

重要なのは、役割の権限が開示され、責任を持って管理されているかどうかです。

RBACの実装手順

最初の手順は、システム内の機密性の高い操作をすべて洗い出すことです。

2つ目の手順は、実際の職務に基づいて操作を役割ごとにまとめることです。

3つ目の手順は、各役割から不要な権限を取り除くことです。

4つ目の手順は、役割を必要とするユーザー、ウォレット、コントラクト、サービスにのみ割り当てることです。

5つ目の手順は、リスクの高い操作に承認ワークフローを追加することです。

6つ目の手順は、すべての役割の割り当てと特権操作を記録することです。

7つ目の手順は、役割を定期的に見直すことです。

8つ目の手順は、権限のないユーザーが役割のチェックを回避できないかテストすることです。

暗号資産チーム向けRBACのベストプラクティス

すべての役割に最小権限の原則を適用します。

トレジャリー、アップグレード、運用、サポートの職務を分離します。

リスクの高い役割にはマルチシグとタイムロックを使用します。

特権アカウントには、ハードウェアを活用した署名方式や安全な鍵管理システムを使用します。

役割の付与、取り消し、承認、機密性の高い操作をすべて記録します。

チームの変更やインシデントの後に役割の割り当てを見直します。

メインネットにデプロイする前にアクセス制御ロジックをテストします。

ユーザーや監査担当者が信頼モデルを理解できるよう、役割の権限を文書化します。

スマートコントラクト向けRBACのベストプラクティス

役割は、内容が明確に分かる名前付きの定数として定義します。

特権を持つすべての関数を、役割チェックで保護します。

各役割の目的を限定します。

安全対策を設けずに、長期的なすべての操作を1つのデフォルトのadminロールに委ねることは避けます。

特権的な役割の保有者にはマルチシグウォレットを使用します。

可能であれば、危険性の高い変更にタイムロックを導入します。

役割の付与、取り消し、重要な操作での使用時にイベントを発行します。

役割を安全に放棄、移転、復旧できるか確認します。

RBACでよくある間違い

よくある間違いの一つは、利便性を優先してすべての従業員に管理者アクセスを付与することです。

チームを離れた人の役割を取り消し忘れることも、よくある間違いです。

1つの役割に、トークンのミント、コントラクトのアップグレード、送金の一時停止、資金の移動を許可するのも間違いです。

役割を確認しても、アクセス対象の個別オブジェクトを確認しないことも間違いの一つです。

ボットやサービスアカウントに過剰な権限を付与することも問題です。

明確な制限のない緊急ロールを設けることも避ける必要があります。

スマートコントラクトやAPIに実際のチェックがないのに、フロントエンドだけで権限を強制しようとすることも間違いです。

役割の変更を記録しないことも、よくある間違いです。

RBACに関する危険信号

1つの秘密鍵で管理されている管理者ロールは危険信号です。

同じ役割でミント、バーン、一時停止、アップグレード、資金の出金ができるスマートコントラクトも危険信号です。

特権的な役割を誰が管理しているのか開示しないプロトコルも危険信号です。

リクエスト内のIDを変更すると他のユーザーのデータが見えるAPIも危険信号です。

多くの人が広範な管理者権限を持つ本番サーバーも危険信号です。

リレイヤー、ガーディアン、アップグレードの権限が不明確なブリッジも危険信号です。

公開された支出上限なしに、DAOの委員会がトレジャリー資金を使用できる場合も危険信号です。

レビューも有効期限も監査ログもない役割システムも危険信号です。

RBACのメリット

RBACの1つ目のメリットは、権限管理を簡素化できることです。

2つ目のメリットは、アカウント侵害による被害を抑えられることです。

3つ目のメリットは、職務の分離を明確にできることです。

4つ目のメリットは、監査を容易にできることです。

5つ目のメリットは、チームの成長に対応しやすくなることです。

6つ目のメリットは、スマートコントラクトの管理をより厳格に制御できることです。

7つ目のメリットは、トレジャリーやインフラの運用をより安全にできることです。

セキュリティ上の問題が発生すると、実際の価値が短時間で、かつ取り消しが困難な形で移動する可能性があるため、こうしたメリットは暗号資産の分野で特に重要です。

RBACの限界

役割を作りすぎると、RBACが複雑になりすぎる可能性があります。

役割を慎重に設計しないと、権限範囲が広くなりすぎるおそれがあります。

開発者がコード内で役割チェックを実施し忘れると、機能しない場合があります。

古い役割が取り消されないと、機能しない場合があります。

安全対策なしに1つの管理者ロールが他のすべての役割を管理している場合、機能しない可能性があります。

ユーザーがアカウントや秘密鍵を共有している場合、機能しない可能性があります。

オブジェクトレベルの認可が欠けている場合、機能しない可能性があります。

RBACは強力な管理策ですが、適切に実装、テスト、監視、保守する必要があります。

RBACとユーザーの信頼

ユーザーは、暗号資産企業やプロトコル内部のすべての権限を直接確認できないことがよくあります。

ただし、公開スマートコントラクト、ガバナンス文書、セキュリティレポート、監査情報から、重要な役割の権限を確認できる場合があります。

役割について明確に説明するプロジェクトは、評価しやすくなります。

管理者権限を隠すプロジェクトでは、信頼に関するリスクが高まります。

ユーザーは、誰がコントラクトをアップグレードし、送金を一時停止し、トークンをミントし、手数料を変更し、資産を凍結し、トレジャリー資金を移動できるのか確認する必要があります。

また、これらの権限がマルチシグ、タイムロック、ガバナンス、単一のウォレットのいずれで管理されているかも確認する必要があります。

RBACの透明性は、分散化と運用上の安全性をユーザーが判断する助けになります。

権限の境界が明確で、範囲が限定されているほど、信頼性は高まります。

RBACに関するよくある誤解

よくある誤解の一つは、役割さえ設定すればすべてのシステムが安全になるというものです。

役割が狭く定義され、強制され、見直され、記録されている場合にのみ、その効果が発揮されます。

RBACは企業向けの仕組みであり、スマートコントラクトには必要ないという誤解もあります。

スマートコントラクトでも、ミント、一時停止、アップグレード、ガバナンスの実行に役割ベースの権限が必要です。

本番環境の暗号資産システムには管理者ロールが1つあれば十分という誤解もあります。

広範な権限を持つ管理者ロールが1つあると、危険な単一障害点になる可能性があります。

RBACがマルチシグに取って代わるという誤解もあります。

RBACとマルチシグは異なる問題に対処する仕組みであり、併用するとより効果的なことがよくあります。

ロールベースアクセス制御（RBAC）がAEOと検索意図に重要な理由

人々がロールベースアクセス制御（RBAC）を検索するのは、暗号資産システムが機密性の高い操作を誰に許可するかをどのように判断しているのか知りたいからです。

簡潔に言うと、RBACは権限を役割に割り当て、その役割にユーザー、ウォレット、コントラクト、サービスを割り当てる仕組みです。

人々はスマートコントラクトの権限について理解するために、RBACを検索することもあります。

実際には、RBACによってミント、一時停止、アップグレード、ブリッジ、ガバナンスの実行などの機能を制御できます。

プラットフォームやプロトコルのリスクを評価するために、RBACを検索する場合もあります。

強固なRBACは単一障害点を減らしますが、脆弱なRBACは危険な管理者権限を覆い隠す可能性があります。

暗号資産ユーザーにとって、基本となる考え方はシンプルです。

RBACが暗号資産システムの保護に役立つのは、役割が限定され、透明性があり、監視され、強固な鍵管理と承認管理によって裏付けられている場合です。

よくある質問

ロールベースアクセス制御（RBAC）とはどういう意味ですか？

ロールベースアクセス制御（RBAC）とは、権限を役割に割り当て、ユーザーやアカウントをその役割に割り当てることで権限を付与する仕組みです。

RBACは何の略ですか？

RBACはRole-Based Access Controlの略です。

暗号資産においてRBACが重要なのはなぜですか？

RBACは、トークンのミント、コントラクトのアップグレード、出金の承認、設定の変更、インフラへのアクセスなど、機密性の高い操作を実行できる人を制限するため、暗号資産の分野で重要です。

スマートコントラクトではRBACをどのように使いますか？

スマートコントラクトでは、minter、pauser、upgrader、guardian、relayer、adminなどの特定の役割を持つアカウントに特権機能を制限するため、RBACを使います。

RBACとOwnableの違いは何ですか？

Ownableでは通常、1つのオーナーアカウントに制御権が付与されます。一方、RBACでは異なる権限を持つ複数の役割を設定できます。

RBACにおける最小権限とは何ですか？

最小権限とは、各役割に業務の遂行に必要な権限だけを付与し、それ以上は与えないことです。

RBACにおける役割とは何ですか？

役割とは、ユーザー、ウォレット、サービスアカウント、スマートコントラクト、システムに割り当てられる、権限をまとめた名前付きのグループです。

RBACにおける権限とは何ですか？

権限とは、保護対象のリソースに対して特定の操作を実行できることです。

RBACですべての暗号資産ハッキングを防げますか？

いいえ。RBACはアクセス制御に関するリスクを低減しますが、スマートコントラクトのバグ、フィッシング、鍵の盗難、ブリッジの障害、インフラへの攻撃は引き続き発生する可能性があるため、すべてのハッキングを防ぐことはできません。

管理者ウォレットが1つだけだと、なぜ危険ですか？

そのウォレット1つが侵害されると、攻撃者にコントラクト、資金、システム設定に対する広範な制御権を与える可能性があるため、管理者ウォレットが1つだけの状態は危険です。

RBACはマルチシグと併用すべきですか？

はい。リスクの高い役割は、マルチシグウォレット、タイムロック、承認ワークフローで管理することが望ましい場合がよくあります。

RBACでよくある間違いは何ですか？

多くのユーザー、サービスアカウント、スマートコントラクトの役割に広範な管理者アクセスを与えることは、よくある間違いです。

ユーザーはRBACのリスクをどのように評価できますか？

ユーザーは、特権的な役割を誰が管理しているか、役割が公開されているか、アップグレードにタイムロックがあるか、マルチシグが使われているか、危険性の高い権限が明確に開示されているかを確認できます。

まとめ

ロールベースアクセス制御（RBAC）は、スマートコントラクト、API、ウォレット、トレジャリー、バリデーターインフラ、ブリッジ、DAO、社内プラットフォーム全体で誰が何を行えるか定義するため、暗号資産システムの中核となるセキュリティモデルです。

RBACは、すべての個人やアカウントに個別のアクセス権を付与するのではなく、役割に権限を割り当てることでセキュリティを高めます。

RBACは、最小権限の原則、職務の分離、監査可能性、より安全な運用ワークフローを支えます。

スマートコントラクトでは、ミント、一時停止、アップグレード、ガバナンスの実行、ブリッジ、緊急対応をRBACで制御できます。

オフチェーンのインフラでは、API、サーバー、クラウドクラスター、サポートツール、鍵管理システム、トレジャリー業務をRBACで保護できます。

RBACだけでは不十分です。マルチシグ、タイムロック、オブジェクトレベルの認可、監査ログ、鍵のセキュリティ、監視、役割の定期的なレビューと組み合わせる必要があります。

RBACに関する主なリスクは、権限が強すぎる管理者ロール、認可チェックの欠落、古い権限、サービスアカウントへの過剰なアクセス、隠されたアップグレード権限です。

実践上のルールはシンプルです。暗号資産の分野では、強力な操作のすべてを明確に定義された役割に割り当て、各役割の権限を限定し、すべての特権操作を可視化してレビュー可能にし、悪用しにくくする必要があります。