RBACとABACの比較: 正しい決断を行う
ロールベースのアクセス制御（RBAC）と属性ベースのアクセス制御（ABAC）は、アクセス制御を実装するためのもっとも一般的な2つの方法です。2つの方法の違いを知ることは、どちらが自分の組織に適切かを判断するのに役立ちます。
RBACは、社内でリクエストしているユーザのロールに基づいてアクセスを許可または拒否します。ABACは、ユーザ、環境、アクセスするリソースに関連する、事前構成されたさまざまな属性または特性を考慮します。
そもそも、アクセス制御とは何か?
会社のネットワークとリソースを安全な建物として考えてみてください。唯一の入り口は、警備員によって警護されており、建物に入ろうとするすべての人のIDが確認されます。自分のIDを証明できない場合、または建物に入るために必要な権限を持っていない場合、その人は追い払われます。このたとえ話では、警備員が企業のシステムインフラストラクチャの基盤を整えるアクセス制御メカニズムのようなものです。
アクセス制御の必要性はどれだけ言っても言い過ぎることはありません。毎年、データ漏洩は企業に数百万ドルの損害を与えており、その多くは、適切なアクセス制御を実装することで回避できます。次のセクションでは、RBACとABACがもたらすものと、両者の違いを探っていきましょう。
ロールベースのアクセス制御（RBAC）とは?
RBACシステムでは、人々にその「ロール」に基づいて権限とアクセス許可が割り当てられます。これらのロールは管理者によって定義され、管理者は人々を部署、責任、年功、地理的場所に基づいて分類します。
例えば、最高技術責任者は企業のすべてのサーバに排他的にアクセスできます。あるソフトウェアエンジニアは、一部のアプリケーションサーバにしかアクセスできません。リモート社員は、アクティブに作業しているサーバにのみアクセスできる、特殊なロールが割り当てらる可能性があります。
アクセスのレベルも、ロールによって異なる可能性があります。例えば、若手社員はデータベースから情報を読み取ることは許可されていますが、何かを追加したり、修正したりすることはできません。しかし、シニアデータベース開発者は、すべてのデータベースに対して最大限の権限を持っています。
アクセスの期間もロールごとに異なる場合があります。例えば、サードパーティの請負業者には外部者ロールを割り当て、サーバへのx時間のアクセスを許可します。一方、社内のソフトウェア開発者は、同じサーバに対して無制限のアクセスが許可されます。
また、1人のユーザに複数のロールを割り当てることも可能です。例えば、ソフトウェアアーキテクトは、異なるプロジェクトに取り組んでいる複数のチームを監督します。このような人は、これらすべてのプロジェクトに関連するすべてのファイルにアクセスする必要があります。このため、管理者は彼らに複数のロールを割り当て、各ロールに特定のプロジェクトのファイルへのアクセスを許可します。
RBACの種類
ロールベースのアクセス制御のNISTモデルは、次のRBACカテゴリを定義します。
フラットRBAC: 各従業員には少なくとも1つのロールが割り当てられますが、複数のロールを割り当てることもできます。新しいファイル/リソース/サーバにアクセスしたい場合、まず新しいロールを取得する必要があります。
階層型RBAC: ロールは年功レベルに基づいて定義されます。上級社員は、自分の権限に加えて部下の権限も所有します。
制約型RBAC: このモデルでは職務の分担（SOD）を導入します。SODは、タスクを実施する権限を複数のユーザに分散し、 不正な活動や高リスクな活動のリスクを軽減します。例えば、開発者がサーバを廃棄したい場合、直属の上司だけでなく、インフラストラクチャの責任者からの承認も必要とします。これにより、インフラストラクチャの責任者は、リスクの高い/不必要なリクエストを拒否できるようになります。
非対称RBAC: すべての組織のロールが定期的にレビューされます。レビューの結果として、権限が割り当てられたり取り消されたり、ロールが追加されたり削除されたりする場合があります。
属性ベースのアクセス制御（ABAC）とは?
ABAC環境では、ユーザがログインするとき、システムはさまざまな属性の基づいてアクセスを許可または拒否します。属性は、以下に関連したものにすることができます。
- ユーザ。ABACの用語では、リクエストしているユーザはサブジェクトとも言います。ユーザ属性には、役職、通常の責任、アクセス権限、部署、 年功などがあります。
例えば、給与アナリストのBobがHRポータルへのアクセスを試みたとします。システムはBobの「部署」、「役職」、「責任」属性をチェックして、アクセスを許可するべきであると判断します。しかし、ITチームのAliceが同じポータルにアクセスしようとすると、必要な属性を持っていないため、アクセスが許可されません。
アクセスされたリソース。これにはリソースの名前とタイプ（ファイル、サーバ、アプリケーション）、作成者と所有者、機密性のレベルが含まれます。
例えば、Aliceは、ソフトウェア開発のベストプラクティスを含む共有ファイルにアクセスしようとします。このファイルの「機密性レベル」属性は低いため、Aliceは所有者ではありませんがアクセスが許可されます。しかし、自分が作業していないプロジェクトのファイルにアクセスしようとすると、「ファイル所有者」と「機密性レベル」属性により、アクセスが拒否されます。
アクション。ユーザがリソースで実施しようとしていることです。関連する属性には、「書き込み」、「読み取り」、「コピー」、「削除」、「更新」、「すべて」などがあります。例えば、Aliceのプロファイルで特定のファイルに対して「読み取り」属性しか設定されていない場合、そのファイルに記述されているソースコードを更新することは許可されません。しかし、「すべて」属性が設定されている人は、どんなことでも実行できます。
環境。検討される属性には、時刻、ユーザとリソースの場所、ユーザのデバイス、ファイルをホストしているデバイスなどがあります。
例えば、Aliceは「ローカル」環境のファイルにアクセスすることは許可されていますが、「クライアント」環境にホストされているファイルにはアクセスできません。
RBACとABAC: 長所と短所
RBACの長所
RBACの短所
ロールの定義と実装は、個人に属性を割り当てるより、はるかに簡単かつ高速です。これは、中小規模の組織の場合、特に有益です。
きめ細かいポリシーを確立するために、管理者はロールを追加し続ける必要があります。これは非常に簡単に「ロールの急増」につながる可能性があり、管理者は組織の何千というロールを管理しなければならなくなります。
アクセス階層を作成して、マネージャが自動的に直属の部下のすべてのアクセス許可を取得できるようにできます。
ロールの急増が起きた場合、ユーザ要件をロールに変換することが非常に複雑なタスクになる可能性があります。
ロールの急増を回避できる場合、RBACの実装に関連するコストは通常、低く抑えられます。
ABACの長所
ABACの短所
きめ細かいアクセス制御ポリシーを定義します。管理者は、多数の属性の中から選択でき、非常に詳細なルールを形成することができます。
特に時間の制約がある状況では、実装が困難な場合があります。
新しいユーザに対応するために既存のルールを修正する必要がありません。管理者に必要なことは、新入社員に適切な属性を割り当てることだけです。
間違ったABAC実装からの回復は、難しく、時間がかかる可能性があります。
アクセス許可を取り消す、または追加する場合、ロールを変更したり新しく作成したりするより、属性を修正する方がはるかに簡単です。
ABACの実装は、多くの場合、時間、リソース、高額なツールがより多く必要であり、全体的な費用が増加します。ただし、ABACの実装が成功した場合、将来性があり、収益が挙げられる投資になる可能性があります。
RBACとABACはどちらが適切か?
ABACはRBACの進化形であると広く考えられていますが、常に正しい選択であるとは限りません。会社の規模、予算、セキュリティニーズに応じて、どちらが適しているかを判断してください。
以下の場合は、ABACを選択してください。
適切なABAC実装を行うための時間、リソース、予算がある。
絶えず成長している大規模組織に所属している。ABACは拡張性を支援します。
労働力が地理的に分散している。ABACでは、場所とタイムゾーンに基づいて属性を追加できる。
可能な限り詳細で柔軟なアクセス制御ポリシーが必要である。
アクセス制御ポリシーを将来性のあるものにしたい。世界は進化しており、RBACは少しずつ時代遅れのアプローチになりつつあります。ABACは、より適切で柔軟なセキュリティ制御を実現します。
以下の場合は、RBACを選択してください。
小規模から中規模の組織に所属している。
組織内に適切に定義されたグループがあり、幅広いロールベースのポリシーを適用することが理にかなっている。
アクセス制御ポリシーを実装するための時間、リソース、予算が限られている。
外部の協力者があまり多くなく、多くの新入社員をオンボードする予定がない。