この記事では、役割ベースのアクセス制御 (RBAC) の完全な説明と、組織のニーズを満たすために RBAC を展開、維持、および拡張するためのステップバイステップ ガイドを提供します。 ロール、ロールを定義する方法、およびロールを使用してアクセスを規制することで、ネットワークを保護し、管理コストを削減し、規制遵守を確保する方法について学習します。 また、役割ベースのアクセス制御の例もいくつか示します。 始めましょう。
役割ベースのアクセス制御 (RBAC) とは何ですか?
組織内での役割に基づいてユーザーに権限を付与するという概念は、役割ベースのアクセス制御 (RBAC) と呼ばれます。 これは、ユーザーに個別にアクセス許可を提供するよりもエラーが発生しにくいアクセス管理への基本的で制御されたアプローチを提供します。
ロール アクセス管理に RBAC を利用する場合は、ユーザーの要求を調べ、共有する職務に基づいてユーザーをロールにグループ化します。 次に、ユーザーごとに、XNUMX つ以上の役割と、各役割に XNUMX つ以上のアクセス許可を割り当てます。 ユーザーを無差別に管理する必要がなくなるため、ユーザーと役割および役割と権限の関係により、ユーザーの割り当てを簡単に行うことができます。
役割ベースのアクセス制御の歴史
少なくとも 1970 年代以降、人々は役割と責任を利用して商用コンピュータ システムへのアクセスを制御してきました。 ただし、これらの方法はアドホックであり、新しいシステムごとにケースバイケースで頻繁に変更する必要がありました。
米国規格協会 (NIST) の研究者は、1992 年まで役割ベースのアクセス制御として知られるシステムの定義を開始しませんでした。その同じ年に、Ferraiolo と Kuhn は、民間およびアプリケーションに適した汎用アクセス制御メカニズムを定義する論文を発表しました。現在使用しているモデルの基礎を築きました。
1990 年代から 2000 年代初頭にかけて、Ferraiolo、Kuhn などは RBAC を改良し、RBAC の経済的利益を調査し、統一モデルを指定し、最も重要なこととして、職務の分割形式を定義するために以前の研究を構築しました。 RBAC は、2004 年に NIST によって業界標準として正式に採用されました。
ロールベースのアクセス制御 RBAC はどのように機能しますか?
ビジネスで RBAC を展開する前に、組織は各役割の権限を徹底的に指定する必要があります。 これには、以下にリストされているカテゴリで権限を正確に指定することが含まれます。
- データ変更権限 (例: 読み取り、書き込み、フル アクセス)
- 会社のソフトウェアを使用するためのアクセス
- プログラム内の権限
RBAC を最大限に活用するには、まず役割と権限をモデル化する必要があります。 適切な特権を確立する特定のジョブにすべてのスタッフの責任を割り当てることは、これの一部です。 その後、組織は従業員のタスクに基づいてポジションを割り当てることができます。
組織は、役割ベースのアクセス制御を使用して、XNUMX つ以上の役割を各ユーザーに割り当てたり、権限を個別に割り当てたりできます。 アイデアは、ユーザーが追加の調整を行わずに職務を完了できるようにする許可を設定することです。
Identity and Access Management (IAM) テクノロジは、組織が RBAC を実装および監視するために使用します。 IAM は主に、すべての ID とアクセス許可をログに記録、監視、更新することで、大規模な組織にサービスを提供します。 権限を割り当てるプロセスは「プロビジョニング」と呼ばれ、権限を取り消すプロセスは「プロビジョニング解除」と呼ばれます。 このタイプのシステムでは、統一された標準化された一連の役割を確立する必要があります。
ロールベースのアクセス コントロール RBAC ロールとは何ですか?
ロールは、組織が権限を構築するために利用できる RBAC アーキテクチャ内のセマンティクスです。 権限、責任、コスト センター、ビジネス ユニット、およびその他の要因を使用して役割を定義できます。
ロールは、ユーザー権限のグループです。 ユーザーの集合体である従来のグループは、役割とは異なります。 アクセス許可は、RBAC のコンテキストでは ID に直接関係するのではなく、ロールに関係します。 ロールはアクセス管理を中心に編成されているため、グループよりも信頼性が高くなります。 アイデンティティは、通常のビジネスにおける特徴や活動よりも頻繁に変化します。
役割ベースのアクセス制御 RBAC モデル
RBAC 標準では、アクセス制御の XNUMX つの形式 (コア、階層、限定) が定義されています。
＃1。 コア RBAC
コア モデルは、役割ベースのアクセス制御システムの主要コンポーネントを定義します。 基本的な RBAC は、スタンドアロンのアクセス制御アプローチとして使用できますが、階層モデルと制限付きモデルの両方の基盤としても機能します。
その結果、すべての RBAC は以下に概説する XNUMX つのルールに従う必要があります。
- 役割の選択または割り当て: 役割を選択または割り当てられた場合にのみ、許可を行使できます。
- 役割の承認: サブジェクトのアクティブな役割は承認されている必要があります。
- 許可の承認: サブジェクトは、サブジェクトのアクティブな役割に対して許可されている権限のみを行使できます。
＃2。 階層 RBAC
防御がすでに破られていると信じることで、潜在的な攻撃に対してより強力なセキュリティ体制を取り、侵害の影響を減らすことができます。 アクセスをセグメント化し、攻撃対象領域を縮小し、エンドツーエンドの暗号化を確認し、リアルタイムでネットワークを監視することにより、侵害によって引き起こされる可能性のある損害の「爆発範囲」を制限します。
＃3。 制約付き RBAC
この XNUMX 番目の RBAC 標準は、コア モデルの役割の分割を拡張します。 職務分離関係は、静的または動的に分類されます。
- XNUMX 人のユーザーが、静的な職務分離 (SSD) 関係 (組織によって定義されている) で相互に排他的な責任を持つことはできません。 これにより、たとえば、XNUMX 人のユーザーが購入と承認の両方を行うことができなくなります。
- 動的職務分離 (DSD) モデルのユーザーは、相反する役割を持つことができます。 ただし、ユーザーは同じセッションで両方のタスクを実行することはできません。 この制約は、たとえば、アクションを承認するために XNUMX 人の一意のユーザーを必要とする XNUMX 人ルールを実装することにより、内部のセキュリティ上の問題を制御するのに役立ちます。
役割ベースのアクセス制御の例
RBAC を使用すると、幅広いレベルと詳細なレベルの両方で、エンド ユーザーが実行できる操作を制御できます。 ユーザーが管理者、スペシャリスト ユーザー、またはエンド ユーザーのいずれであるかを指定でき、責任とアクセス許可を従業員の組織上の地位に一致させることができます。 アクセス許可は、従業員がタスクを遂行するのに十分なアクセス権を持つ場合にのみ付与されます。
エンドジョブ ユーザーの説明が変更された場合はどうなりますか? 役割を別のユーザーに手動で付与する必要がある場合や、役割を役割グループに割り当てるか、役割割り当てポリシーを使用して役割グループ メンバーを追加または削除することができます。
RBAC ツールには、次の指定が含まれる場合があります。
- 管理役割の範囲 – 役割グループが処理できるアイテムを制限します。
- 管理役割グループ – 管理役割グループのメンバーを追加および削除できます。
- 管理者の役割 – これらは、特定の役割グループが実行できるタスクのタイプです。
- 管理役割の割り当て - これは、役割グループに役割を割り当てるプロセスです。
ユーザーが役割グループに追加されると、ユーザーはそのグループ内のすべての役割にアクセスできるようになります。 それらが削除されると、アクセスが制限されます。 ユーザーが特定のデータまたはアプリケーションへの一時的なアクセスを必要とし、プロジェクトの終了後に削除される場合は、ユーザーを多数のグループに割り当てることもできます。
その他のユーザー アクセスには、次のようなものがあります。
- 特定のアカウントまたは役割の主要な連絡先。
- 請求 - 単一のエンドユーザーの請求先アカウントへのアクセス。
- テクニカル ユーザーは、技術的な業務を行うユーザーです。
- 管理アクセスは、管理活動を行うユーザーに付与されます。
RBAC の代替手段: アクセス制御の種類
役割ベースのアクセス制御の代わりに、他のアクセス制御メカニズムを使用できます。
アクセス制御リスト（ACL）
アクセス制御リスト (ACL) は、コンピューティング リソースに関連付けられているアクセス許可を一覧表示するテーブルです。 オブジェクトにアクセスできるユーザーと、オブジェクトに対して実行できるアクションについて、オペレーティング システムに通知します。 各ユーザーには、各アイテムのセキュリティ プロパティにリンクされたエントリがあります。 従来の DAC システムでは、通常、ACL が使用されます。
ACL と RBAC
セキュリティと管理コストの点では、RBAC はほとんどのビジネス アプリケーションで ACL より優れています。 ACL は、個々のユーザー レベルおよび低レベルのデータでセキュリティを実装するのにより適していますが、RBAC は、管理者が監督する全社的なセキュリティ システムにより適しています。 たとえば、ACL は特定のファイルへの書き込みアクセスを有効にできますが、ユーザーによるファイルの変更方法を定義することはできません。
属性ベースのアクセス制御 (ABAC)
ABAC は、環境、システム、オブジェクト、またはユーザー情報などの特定の品質に基づいてアクセス許可を制御するために、一連のルールとポリシーを評価します。 ブール論理を使用して、アトミックまたはセット値のプロパティとそれらの関係の複雑な評価に基づいて、人々のアクセスを許可または拒否します。
実際には、これにより、Role=Manager や Category=Financial などのキーと値の組み合わせを使用するルールを eXtensible Access Control Markup Language (XACML) で定義できます。
ABAC 対 RBAC
RBAC は事前定義された役割に基づいていますが、ABAC はより動的で、関係ベースのアクセス制御を使用します。 RBAC は幅広いストロークでアクセス制御を定義するために使用できますが、ABAC はより細分性を提供します。 たとえば、RBAC システムはすべてのマネージャーにアクセスを許可しますが、ABAC ポリシーは財務部門のマネージャーにのみアクセスを許可します。 ABAC はより複雑な検索を行うため、より多くの処理能力と時間が必要になるため、RBAC が不十分な場合にのみ使用します。
RBAC の利点
- ネットワーク アクセスの管理と監査は、情報セキュリティにとって重要です。 知る必要性に基づいて、アクセスを許可することができ、また許可する必要があります。 ビジネス内での各ユーザーの役割に基づいて重要な情報への不要なアクセスを制限することにより、数百人または数千人の従業員のセキュリティをより簡単に管理できます。 その他の利点は次のとおりです。
- 管理および IT サポートは削減されます。 従業員が雇用されたり役割が変わったりした場合、RBAC を使用して事務処理やパスワード変更の必要性を減らすことができます。 代わりに、RBAC を利用して、オペレーティング システム、プラットフォーム、およびアプリケーション間で役割を迅速に追加および転送できます。 また、ユーザー権限を付与する際のエラーの可能性も減少します。 RBAC の多くの経済的利点の XNUMX つは、管理活動に費やされる時間の削減です。 また、RBAC は、事前定義されたロールを割り当てることで、サードパーティ ユーザーをネットワークに統合することも容易にします。
- 運用効率の向上。 RBAC は、論理的な定義による合理化されたアプローチを提供します。 下位レベルのアクセス制御を管理しようとする代わりに、すべての役割を企業の組織構造に合わせて調整できるため、ユーザーはより効率的かつ自律的に職務を遂行できます。
- コンプライアンスの向上。 連邦、州、地方自治体の制限は、すべての組織に適用されます。 企業は、RBAC システムを導入することで、プライバシーと機密保持に関する法定および規制基準をより簡単に満たすことができます。これは、IT 部門と幹部がデータのアクセス方法と利用方法を管理できるためです。 これは、PHI や PCI などの機密データを大量に扱う医療機関や金融機関にとって特に重要です。
RBAC 実装のベスト プラクティス
組織への RBAC の実装は、安易に行うべきではありません。 不必要な混乱や職場の苛立ちを引き起こさずにチームを参加させるには、いくつかの一般的な段階があります。 ここでは、いくつかのアイデアを紹介します。
- 現在のステータス： セキュリティを備えたすべてのソフトウェア、ハードウェア、アプリのリストを作成します。 これらの大部分はパスワードを必要とします。 ただし、鍵がかかっているサーバー ルームを含めることもできます。 物理的なセキュリティは、データ保護の重要な要素になる可能性があります。 また、これらの各プログラムと場所に誰がアクセスできるかを指定します。 これにより、現在のデータ状況を垣間見ることができます。
- 現在の職務: 正式な名簿と役割のリストがなくても、個々のチーム メンバーが何をするかを決めるのは、ちょっとした会話と同じくらい簡単かもしれません。 創造性や現在の文化 (楽しんでいる場合) を妨げないようにチームを編成するように努めてください。
- ポリシーを作成します。 すべての変更は、現在および将来のすべての作業者が表示できるように文書化する必要があります。 RBAC ソリューションを利用している場合でも、新しいシステムを明確に説明する文書を用意しておくと、問題を防ぐのに役立ちます。
- 変更： 現在のセキュリティ ステータスとロールが判明したら (そしてポリシーが設定されたら)、変更を実装します。
- 継続的に適応する: 最初の RBAC 反復では、何らかの変更が必要になる可能性があります。 早い段階で、自分の職務とセキュリティ ステータスを頻繁に評価する必要があります。 最初に、クリエイティブ/制作プロセスがどの程度うまく機能しているかを評価し、次にプロセスがどの程度安全かを評価します。
まとめ
データ保護は、どの企業にとっても重要なビジネス機能です。 RBAC システムは、会社の情報がプライバシーおよび機密保持法に準拠していることを保証できます。 さらに、組織に競争上の影響を与える知的財産へのアクセスなど、重要なビジネス活動を保護できます。
役割ベースのアクセス制御に関するよくある質問
RBAC の XNUMX つの主要なルールは何ですか?
役割のアクセス許可、ユーザーと役割、役割と役割の関係などの RBAC コンポーネントにより、ユーザーの割り当てが簡単になります。
ACL が使用される理由
ネットワーク トラフィックを削減して、ネットワーク パフォーマンスを向上させます。 ユーザーがアクセスできるサーバー/ネットワーク/サービスのセクションを指定するネットワーク セキュリティ レベル。 システムに出入りするトラフィックの詳細な追跡。
ロールベースのアクセス制御とルールベースのアクセス制御の違いは何ですか?
従業員のアクセス レベルは、本質的に予防的なルール ベースのアクセス制御によって決定されません。 代わりに、不要なアクセスを防止するために機能します。 役割ベースのモデルは、承認されたアクセス権を取得できる一連の条件を従業員に提示するという点で積極的です。
- 随意アクセス制御: 定義と例
- 必須のアクセス制御 MAC: 仕組み
- Active Directory 管理ツール: その概要と知っておくべきこと
- マーケティング部門：概要、構造、役割、期待（+無料のヒント）
- 仮想管理アシスタント：仕事、サービス、会社、要件、および必要なすべて。
参考文献
