役割ベースのアクセス制御 (RBAC) を使用すると、ネットワーク管理者は組織内の役割に応じてユーザーのアクセス レベルを調整できます。一方、ルールベースのアクセス制御 (RuBAC) では、特定の条件を遵守する個人に応じてアクセスが許可されます。事前定義されたルールベースのアクセス制御システムを採用することで、システム管理者は、たとえば、標準の営業時間内にのみ特定のネットワーク リソースへのアクセスを許可できます。
RuBAC は属性ベースの制御と呼ばれることが多く、組織内での役割や立場に関係なく、設定された基準に基づいてユーザーにさまざまなレベルのシステムへのアクセスを許可します。この説明は、Dell Technologies のサイバーセキュリティ、アイデンティティ、およびアクセス管理担当副社長である Joe Dowling 氏によるものです。
通信サービス プロバイダーである AlxTel のシニア ソリューション アーキテクト兼 CTO である Alaa Negeda 氏は、ネットワーク アクセス制御以外にも、RuBAC はファイルやディレクトリのアクセス制御、アプリケーションのアクセス制御など、さまざまな状況で使用できると述べています。同氏は、RuBAC はファイアウォール、侵入検知システム、パスワード保護などの他のセキュリティ対策と統合することもできると付け加えました。
RuBAC 設定は、組織内での特定の役割に基づいてユーザーに提供される制御の範囲によって定義されます。分析ソフトウェア プロバイダーである SAS の ID およびアクセス管理のグローバル責任者である Alexander Marquardt 氏は、RuBAC によって個別の基準、条件、または制約に基づいたアクセス制御が可能になると指摘しています。このアプローチは明示的で非常に詳細であり、サブジェクト、オブジェクト、または動作環境の個々の属性や特性に焦点を当てています。
貨物および物流サービス プロバイダーである XPO の CIO である Jay Silberkleit 氏は、最大限のカスタマイズと柔軟性を提供するネットワーク アクセス方法を求める組織にとって、RuBAC が最適な選択肢であると考えています。同氏は、組織構造の全体的な定義を変更することなく、ルールを迅速に変更できると指摘しています。
Marquardt 氏は、RuBAC を使用することの主な利点は、細分性と明瞭さであると述べています。ルールは特定のオブジェクトまたは操作へのアクセスを明示的に許可または拒否するため、ルールを調べるときにあいまいさはありません。
制御性と適応性の向上も、多くの組織が RuBAC を選択する理由です。 Marquardt 氏によると、ルールベースのアクセス制御は、確固たる明示的なルールを必要とする企業にとって理想的なモデルです。
RuBAC は、最小限のオーバーヘッドで事実上無制限のユーザー アクセスの柔軟性を導入者に提供します。 Silberkleit が説明するように、少数のルール セットを調整することで、大規模なユーザー ベースを促進することができます。このアプローチにより、さまざまなネットワーク アクセス レベルをユーザーのサブセット間でテストまたは実験できるようになります。このようにアクセスをきめ細かく制御することで、組織の機敏性と安全性を維持できると彼は付け加えました。
RuBAC の主な欠点は、ルールの確立、構成、設定、テストに必要な監視と管理のレベルが高いことです。企業はまた、ユーザーの役割が進化するにつれて、アクセス許可の正確さと信頼性を確保するという課題にも直面しています。組織は、RuBAC の設定と管理のための明確な戦略から始める必要があると、Dell の Dowling 氏は警告します。
Marquardt 氏は、採用者は、広く適用されるルールに対して単一サブジェクトまたは単一オブジェクトの例外を記述し、それらの例外を追跡し、有効な権利と許可を正確に報告することに苦労する可能性があると指摘しています。
Druva のチーフ テクニカル エバンジェリストである W. Curtis Preston 氏は、特に多要素認証 (MFA) が関係する場合、RuBAC の主な欠点として、面倒なセットアップ プロセスと継続的なメンテナンス作業を挙げています。しかし、サイバー攻撃と侵害に関する現在の知識に基づけば、組織の安心とデータ保護のために支払う代償はわずかである、と同氏は主張します。
RuBAC ルールのカスタマイズは困難な場合があることを Negeda 氏は認めています。たとえば、特定の役割に必要な正確な権限を定義する必要がある場合や、特定の役割に関連付けられたユーザー名またはグループ名を指定する必要がある場合があります。
Negeda 氏は、RuBAC のスケーリングが難しい場合があるとも述べています。多数のリソースに対するルールの作成と維持は、どのユーザーまたはグループがどのリソースにアクセスできるかを決定するのと同様に、困難な場合があります。
Negeda 氏によると、RuBAC を導入する方法は数多くありますが、データベースを使用してルールを保存する方法が最も一般的な戦略です。ルールを作成すると、管理者はルールを簡単に追加または更新できます。
混乱と中断を最小限に抑えるために、Dowling 氏は、RuBAC への移行を検討している組織は、継続的なビジネス要件と既存のネットワーク アクセス分類システムを分析して、ルールベースのアクセスとロールベースのアクセスのどちらが最適なモデルであるかを判断することから始めることを推奨しています。 RuBAC が組織にとって理想的な選択である場合は、システムのビジネス オーナーとの包括的なインタビューを実施して、従うべき最も複雑でないルールセットを確立する必要があります。
AppMasterのようなlow-codeおよびno-code開発プラットフォームの台頭により、アプリケーションとデータを保護するためにアクセス制御システムの実装がさらに重要になっています。ロールベース、ルールベース、ハイブリッドのいずれのアプローチであっても、組織に適したアクセス制御方法を見つけることは、安全で機能的なネットワーク環境を維持するのに役立ちます。
