要約
適切なアクセス制御モデルを選択することは、セキュリティの基礎となる重要な決定です。ロールベースのアクセス制御(RBAC)は、事前定義されたロールに基づいて権限を付与するもので、小規模な組織や明確に構造化された組織にとっては、迅速かつシンプルな方法です。属性ベースのアクセス制御(ABAC)は、ユーザーの特性、リソースの機密性、時間、場所といった、より豊富な条件を評価するため、複雑な環境や動的な環境に最適です。多くの組織では、広範なアクセス層にはRBACを、きめ細かな制御にはABACを使用するハイブリッドアプローチが、両方の利点を最大限に活かせる方法であると認識されています。
RBACとABACの違いは何ですか?
RBACとABACの主な違いは、アクセスを許可する方法です。RBACは、ロール別にアクセスを許可する手法です。 ABACは、ユーザーの特性、オブジェクトの特性、アクションタイプなどによってアクセスを決定する手法です。
ロールベースアクセス制御(RBAC)と属性ベースアクセス制御(ABAC)の違いを理解することで、賢明な判断を下すことができます。
RBACとは?
RBACを使用する場合、コンピュータシステムにログインした人に許可される操作は、その人の役割によって異なります。
RBACで「ロール」という用語は、通常は、以下のような特性を共有する人々のグループを指します。
- 部署
- 場所
- 組織内の階級
- 職務
ロールを定義すると、以下のようなアクセス許可を割り当てることができます。
- アクセス。その人に何が表示されるか?
- オペレーション。その人は何を読みとることができるか?その人は何を書き込むことができるか?その人はファイルの作成や削除を実行できるか?
- セッション。その人はどのくらいの期間システムにとどまることができるか?いつからログインできるか?ログインの有効期限はいつか?
すべてのRBACシステムはこのように動作します。ただし、米国国立標準技術研究所は、さらに柔軟性が必要な場合に備えて、RBACの4つのサブタイプを定義しています。
| レベル | 名前 | Description |
| レベル1 | フラット | すべての従業員は、アクセス許可を定義する少なくとも1つのロールを持ちますが、中には複数のロールを持つ人もいます。 これはRBACの最もシンプルな形態です。 |
| レベル2 | 階層型 | 役職レベルは、各ロールがどのように連携するかを定義するものです。上級役員は、自身の権限に加えて、部下が持つ権限も保有しています。フラットなRBACルールを基盤に、ロール階層を追加します。 |
| レベル3 | 制約がある | 職務分掌が追加され、1つのタスクに複数人で取り組みます。これにより、セキュリティを確保し、不正行為を防止できます。階層型RBACを基盤としています。 |
| レベル4 | 対称 | 役割のアクセス許可は頻繁に見直され、その結果としてアクセス許可が変更されます。 制約付きRBACモデルをベースに、権限レビューを追加します。 |
ABACとは?
コンピュータシステムにログインした人が実行できる操作を決定するときに、ABACプロトコルを使うことで、ユーザー、リソースの属性、環境に応じた設定を実現できます。
ABACを使用するシステムの管理者は、以下の方法でアクセス許可を設定できます。
- ユーザー。その人の職位、典型的なタスク、または階級によって、実行できる作業が決まることがあります。
- リソース属性。ファイルの種類、その作成者、ドキュメントの機密性によってアクセスが決まることがあります。
- 環境その人がファイルにアクセスする場所、時間帯、または日付によって、アクセスが決定することがあります。
ABACの権限は、実際にはどのように機能するのでしょうか?
このようなシステムでは、管理者は細かな区別を使用して制御を実行できます。さまざまな属性に基づいてアクセス許可を設定でき、それらが連携してドキュメントを安全に保ちます。理論的には、ログインした場所や、曜日によって、同じ人に対してアクセス許可を変化させることも可能です。
ABACでは、各要素が連携して動作します。
- サブジェクト:誰が作業を実行しようとしていますか?
- オブジェクト:ユーザーがネットワーク内で操作しようとしているファイルはどれですか?
- オペレーション。その人は、そのファイルで何をしようとしているのか?
関係性は、以下のようにif/then文で定義されます。
- ユーザーが会計部門に所属している場合、その人は会計ファイルにアクセスできます。
- その人がマネージャーである場合、ファイルの読み書きを実行できます。
- 会社の方針で「土曜日は作業しない」と定められており、今日が土曜日である場合、今日は誰もファイルにアクセスできません。
RBACとABACのメリットとデメリットは何ですか?
RBACとABACはどちらも、制御とアクセスに関係しています。どちらのアプローチもシステムを保護しますが、それぞれに明確な長所と短所があります。
RBACの長所 | RBACの短所 | ABACの長所 | ABACの短所 |
シンプルさ | ロールの爆発 | 明確に定義された制御 | 時間的な制約 専門知識 |
RBAC、ABAC、またはハイブリッドアプローチは、どのような場合に使い分けるべきでしょうか?
以下の例は、どのような場合にRBACシステムが最適で、どのような場合にABACシステムがよりよく機能するかを理解するのに役立ちます。また、両者を併用した例も紹介します。
以下を参考に、RBACとABACを比較・検討してください。
- 小規模なワークグループ。RBACが最適です。会社の規模が小さく、ファイルの数が少ない場合は、ロールごとに作業を定義することがシンプルです。たとえば、15人が従業員しかいない建設会社であれば、RBACシステムを効率的かつ簡単にセットアップできます。
- 地理的に分散した作業グループ。 ABACが適しています。 従業員のタイプ別、場所別、業務時間別にアクセスを定義できます。たとえば、支店のタイムゾーンにおける業務時間中のみアクセスを許可できます。
- 期間限定のワークグループ。ABACの使用が望ましいと言えます。 機密性の高い文書やシステムの中には、勤務時間外にアクセスできないようにすべきものがあります。ABACシステムでは、時間ベースのルールを設定できます。
- 単純に構造化された作業グループ。 RBACが最適です。大規模な組織で、職務に応じてアクセスを定義できます。たとえば、医院では受付担当者にスケジュールの読み書きを許可していますが、その従業員は医療検査結果や請求情報を見る必要はありません。このような場合には、RBACシステムが有用です。
- クリエイティブ企業クリエイティブ企業は独自のファイル利用方法をとることが多いため、ABACが理想的です。誰もが特定のドキュメントを閲覧する必要がある場合もあれば、少数の人しか閲覧する必要がない場合もあります。アクセスニーズは、ロールではなくドキュメントによって変化します。例えば、社内のアーティストやライターなどのクリエイティブスタッフは、他の従業員が簡単に配布できるファイルを作成します。しかし、請求部門やアカウントエグゼクティブなどの従業員が、そうしたファイルを確認する必要がある場合もあります。そして、マーケティングチームがそれらを共有したいと考えるかもしれません。誰がこれらのドキュメントを閲覧し、どのように扱うべきかという複雑な問題は、ABACを使用することで最適に解決できます。
RBACとABACのハイブリッドアプローチが有効な場合とは?
多くの場合、RBACもABACも、必要なすべてのユースケースに対応する完璧なソリューションではありません。そのため、一般的には、大局的なアクセスにRBACを使用し、その構造の中で細かい制御にABACを使用するというハイブリッドシステムが採用されます。
たとえば、RBACシステムを使って、機密性の高いサーバーを新入社員から隠すことができます。さらに、アクセス権を持つ人がどのようにドキュメントを操作できるかを、ABACシステムを使って管理できます。
RBACとABACを組み合わせることで、管理者は両方のシステムの長所を活かすことができることが、研究で示されています。RBACは機密ファイルを緊密に保護し、ABACは動的な動作を可能にします。それらを組み合わせることで、両方の長所が活かされます。
賢い選択をするために
どのアイデンティティ管理モデルが自社に最適かわかりませんか? 問題ありません。
Oktaが、きめ細かなアクセス許可とユーザーのアクセス要素を使用して、アクセスと認可のための安全なパスを作成します。Oktaの活用法をご確認ください。
よくある質問(FAQ)
ロールベースのアクセス制御(RBAC)と属性ベースのアクセス制御(ABAC)の主な違いは何ですか?
RBACは、ユーザーに事前定義されたロール(部署、役職、職務など)に基づいてアクセスを許可するのに対し、ABACは、ユーザーの特性、リソースの種類、環境、時間など、より広範な属性を評価してアクセスを決定します。
組織にとってロールベースのアクセス制御(RBAC)がより優れた選択肢となるのは、どのような場合でしょうか?
RBACは、小規模なワークグループ、単純な構造の組織、または職務によってアクセスが明確に定義されている企業に最適です。例えば、スタッフの役割が明確に分かれている小規模な建設会社や診療所などは、RBACに適しています。
大規模な組織でロールベースのアクセス制御(RBAC)を使用するリスクとは何ですか?
組織が成長し、より詳細な権限設定を試みるにつれて、管理者がロールを作成しすぎる可能性があります。その結果、管理が困難な数百から数千ものルールを持つ「ロール爆発」と呼ばれる状態に陥ります。
属性ベースのアクセス制御(ABAC)では、どのような種類の条件を使用してアクセスを制御できますか?
ABACは、ユーザー属性(役職、職位)、リソース属性(ファイルの種類、機密度、作成者)、環境要素(場所、時間帯、曜日)を評価して、アクセスを許可するかどうかを判断します。
ロールベースのアクセス制御(RBAC)と属性ベースのアクセス制御(ABAC)は併用できますか?
はい。多くの組織では、RBACで広範な高レベルのアクセス層を処理し、ABACでそれらの層内にきめ細かな制御を適用するハイブリッドモデルが使用されています。RBACのシンプルさとABACの動的な柔軟性を両立させます。
米国国立標準技術研究所(NIST)が定義する、ロールベースのアクセス制御(RBAC)の4つのサブタイプとは何でしょうか?
NISTは、RBACの4つのサブタイプとして、「フラット」(基本的なロールベースの権限)、「階層」(年功序列によるロールの継承)、「制約付き」(複数人での職務分掌)、「対称」(定期的な権限レビュー)を定義しています。
参考文献
The NIST Model for Role-Based Access Control: Towards a Unified Standard. (July 2007). National Institute of Standards and Technology.
RBACおよびABACにおけるポリシーエンジニアリング。(2018年11月)。データベースからサイバーセキュリティへ。
ロールベースアクセス制御への属性の追加。(2010年6月)。IEEE Computer。
最小特権を実装するためのロールベースABACモデル(2019年2月)。ICSCA '19: Proceedings of the 2019 8th International Conference on Software and Computer Applications.
ロールを定義すると、以下のようなアクセス許可を割り当てることができます。
- アクセス。その人に何が表示されるか?
- オペレーション。その人は何を読みとることができるか?その人は何を書き込むことができるか?その人はファイルの作成や削除を実行できるか?
- セッション。その人はどのくらいの期間システムにとどまることができるか?いつからログインできるか?ログインの有効期限はいつか?
すべてのRBACシステムはこのように動作します。ただし、米国国立標準技術研究所は、さらに柔軟性が必要な場合に備えて、RBACの4つのサブタイプを定義しています。
- フラット:すべての従業員は、権限を定義する役割を少なくとも1つは持っていますが、複数の役割を持っている人もいます。
- 階層型:役職の連携方法を職位で定義します。上級幹部は自身のアクセス許可を持つとともに、部下に付与されるアクセス許可も持ちます。
- 制約付き:職務分掌が追加され、複数の人が1つのタスクを共同で実行します。これは、セキュリティの確保と不正行為の防止に役立ちます。
- 対称:役割のアクセス許可は頻繁に見直され、その結果としてアクセス許可が変更されます。
これらの役割は相互に関連し、セキュリティレベルごとに編成できます。
- レベル1、フラット:これは最も単純な形式のRBACです。従業員はロールを使ってアクセス許可を獲得します。
- レベル2、階層型:これはフラットRBACルールに基づいて構築され、ロール階層を追加します。
- レベル3、制約付き:これは階層型RBACを基盤としており、職務の分離を追加します。
- レベル4、対称型:これは制約付きRBACモデルをベースにしており、アクセス許可のレビューを追加します。
属性ベースのアクセス制御とは?
コンピュータシステムにログインした人が実行できる操作を決定するときに、ABACプロトコルを使うことで、ユーザー、リソースの属性、環境に応じた設定を実現できます。
ABACを使用するシステムの管理者は、以下の方法でアクセス許可を設定できます。
- ユーザー。その人の職位、典型的なタスク、または階級によって、実行できる作業が決まることがあります。
- リソース属性。ファイルの種類、その作成者、ドキュメントの機密性によってアクセスが決まることがあります。
- 環境その人がファイルにアクセスする場所、時間帯、または日付によって、アクセスが決定することがあります。
このようなシステムでは、管理者は細かな区別を使用して制御を実行できます。さまざまな属性に基づいてアクセス許可を設定でき、それらが連携してドキュメントを安全に保ちます。理論的には、ログインした場所や、曜日によって、同じ人に対してアクセス許可を変化させることも可能です。
ABACでは、各要素が連携して動作します。
- サブジェクト:誰が作業を実行しようとしていますか?
- オブジェクト:ユーザーがネットワーク内で操作しようとしているファイルはどれですか?
- オペレーション。その人は、そのファイルで何をしようとしているのか?
関係性は、以下のようにif/then文で定義されます。
- ユーザーが会計部門に所属している場合、その人は会計ファイルにアクセスできます。
- その人がマネージャーである場合、ファイルの読み書きを実行できます。
- 会社の方針で「土曜日は作業しない」と定められており、今日が土曜日である場合、今日は誰もファイルにアクセスできません。
RBACとABACの比較:長所と短所
RBACとABACはどちらも、制御とアクセスに関係しています。どちらのアプローチもシステムを保護しますが、それぞれに明確な長所と短所があります。
ABACの長所 | ABACの短所 |
明確に定義された制御 | 時間的な制約 |
専門知識 |
RBACの長所 | RBACの短所 |
シンプルさ | ロールの爆発 |
5つのアイデンティティ管理シナリオ
以下の例は、どのような場合にRBACシステムが最適で、どのような場合にABACシステムがよりよく機能するかを理解するのに役立ちます。また、両者を併用した例も紹介します。
以下を参考に、RBACとABACを比較・検討してください。
1. 小規模なワークグループ。RBACが最適です。会社の規模が小さく、ファイルの数が少ない場合は、ロールごとに作業を定義することがシンプルです。
たとえば、15人が従業員しかいない建設会社であれば、RBACシステムを効率的かつ簡単にセットアップできます。
2. 地理的に多様なワークグループ。ABACは良い選択です。従業員のタイプ別、場所別、業務時間別にアクセスを定義できます。たとえば、支店のタイムゾーンにおける業務時間中のみアクセスを許可できます。
3. 時間定義されたワークグループABACが推奨されます。一部の機密文書またはシステムは、営業時間外にはアクセスできないようにする必要があります。ABACシステムでは、時間ベースのルールを設定できます。
4. 単純な構造のワークグループ。RBACが最適です。大規模な組織で、職務に応じてアクセスを定義できます。
たとえば、医院では受付担当者にスケジュールの読み書きを許可していますが、その従業員は医療検査結果や請求情報を見る必要はありません。このような場合には、RBACシステムが有用です。
5. クリエイティブ企業クリエイティブな企業では、ファイルを独自の方法で使用することが多いため、ABACが理想的です。ドキュメントによって、全員が見る必要がある場合もあれば、一部の人だけが見る必要がある場合もあります。アクセスのニーズは、役割ではなくドキュメントに応じて変わります。
たとえば、社内のアーティストやライターなどのクリエイティブスタッフは、他の従業員が配布しやすいようにファイルを作成します。しかし、請求部門やアカウントエグゼクティブなどの従業員も、それらのファイルを見る必要があるかもしれません。また、マーケティングチームが共有する場合もあるでしょう。
これらのドキュメントを誰が見るべきか、どのように扱うべきかという複雑なアクセスは、ABACで管理するのが最善です。
多くの場合、RBACもABACも、必要なすべてのユースケースに対応する完璧なソリューションではありません。そのため、一般的には、大局的なアクセスにRBACを使用し、その構造の中で細かい制御にABACを使用するというハイブリッドシステムが採用されます。
たとえば、RBACシステムを使って、機密性の高いサーバーを新入社員から隠すことができます。さらに、アクセス権を持つ人がどのようにドキュメントを操作できるかを、ABACシステムを使って管理できます。
RBACとABACを組み合わせることで、管理者は両方のシステムの長所を活かすことができることが、研究で示されています。RBACは機密ファイルを緊密に保護し、ABACは動的な動作を可能にします。それらを組み合わせることで、両方の長所が活かされます。
賢い選択をするために
どのID管理モデルが組織に最適かわかりませんか?問題ありません。
Oktaが、きめ細かなアクセス許可とユーザーのアクセス要素を使用して、アクセスと認可のための安全なパスを作成します。Oktaの活用法をご確認ください。
参考文献
The NIST Model for Role-Based Access Control: Towards a Unified Standard. (July 2007). National Institute of Standards and Technology.
RBACおよびABACにおけるポリシーエンジニアリング。(2018年11月)。データベースからサイバーセキュリティへ。
ロールベースアクセス制御への属性の追加。(2010年6月)。IEEE Computer。
最小特権を実装するためのロールベースABACモデル(2019年2月)。ICSCA '19: Proceedings of the 2019 8th International Conference on Software and Computer Applications.