[解決済み] ASP.NET MVCにおけるロールベースアクセスコントロール（RBAC）とクレームベースアクセスコントロール（CBAC）の比較

質問

を使用する主な利点は何ですか？ CBAC vs. RBAC ? CBACを使うのが良い場合とRBACを使うのが良い場合とは？

CBACモデルの一般的な概念を理解しようとしているのですが、一般的な考え方がまだよくわかりません。

どのように解決するのですか？

Role/Claim/Permission-based Access Controlのコンセプトを平易な言葉で説明します。ここで紹介するコード・スニペットは疑似コードで、コンパイルできる場合とできない場合があります。

ロールとは何ですか？

ロールは、役職名と考えることができます。例えば、セールスマネージャー、マーケティングマネージャー、アドミニストレーターなどです。

クレームとは何ですか？

クレームはRoleよりも広い範囲をカバーすることができます。ClaimはTAGと考えることができます。例えば、ある人物に「フレンドリー」「おしゃべり」「ヨーロッパ人」「写真家」「18歳の大人」等のタグを付けることができます。技術的には、ロールもクレームと考えることができます。

役割に基づくアクセス制御

とてもシンプルです。言葉を使う代わりに、いくつかの例を示しましょう。 例えば、ロール（役割）をチェックすることで、ウェブサイトのいくつかのページへの訪問を許可するとします。こんな感じです。

    [Authorize(Roles="Sales Manager")]
    public ActionResult CreateCustomer()
    {
        return View();
    }

    [Authorize(Roles="Marketing Manager")]
    public ActionResult EditLandingPage()
    {
        return View();
    }

クレームベースのアクセス制御

平たく言うと、Claims Based Access Controlでは、ページへのアクセスを決定する際に、ロールの代わりにクレームをチェックします。

(これは擬似的なコードです。ClaimsAuthorizeはMVCの組み込みクラスではなく、NuGetのパッケージを利用するか、自分で書いてください)

    [ClaimsAuthorize(Claims="Senior-Employee, Award-Winner-Employee, Experienced-On-Sales")]
    public ActionResult CreateCustomer()
    {
        return View();
    }


    [ClaimsAuthorize(Claims="Trust-worthy-Employee, President")]
    public ActionResult DeleteCustomer()
    {
        return View();
    }

    [ClaimsAuthorize(Claims="Adult-over-18years")]
    public ActionResult ViewImagesOfViolence()
    {
        return View();
    }

ロールをチェックする代わりに、ユーザーが主張する人物に基づいてページへの訪問を許可していることに注目してください。

RBACとCBACの比較

では、役割ベースのアクセス制御と請求ベースのアクセス制御のどちらが優れているかというと、このページ(ViewImagesOfViolence")について考えてみてください。そのページへの訪問を許可するかどうかを判断するときに、Adult-over-18yearsというクレームをチェックする方が直感的ではありませんか？つまり、Claimを使うことで、ロール（役割）を比較するユーザーのセグメントをより多く作ることができるのです。抽象的な意味では、すべてのロールもクレームになり得ますが、クレームをロールとして考えることはできません。

パーミッションに基づくアクセス制御

ページの閲覧を許可する際にRolesやClaimをチェックするのではなく、Permissionベースのアクセス制御を考える必要があります。そのために必要なことを紹介します。

ロールベースの認証を使用する場合、顧客を作成するアクションがあり、「Sale」ロールの人がそれを行えるようにしたい場合、次のようなコードを記述します。

[Authorize(Roles="Sale")]
public ActionResult CreateCustomer()
{
    return View();
}

その後、「Marketing」ロールの人がCustomerを作成できるようにする必要があることに気づきました。そして、Actionメソッドを次のように更新します。

[Authorize(Roles = "Sale", "Marketing")]
public ActionResult CreateCustomer()
{
    return View();
}

今、あなたは、一部のマーケティング担当者が顧客を作成できないようにする必要があることに気づきましたが、マーケティング担当者に別の役割を割り当てることはできません。そこで、すべてのマーケティング担当者が顧客を作成できるようにすることを余儀なくされます。

マーケティング担当者に顧客の作成を許可することにした場合、MVC Action メソッドの Authorize 属性をすべて更新し、アプリケーションをコンパイルし、テストし、デプロイしなければならないのです。何日か後に、マーケティングではなく、他のロールにタスクを許可することに決めました。そこで、コードベース内を検索し、Authorize属性からすべての「マーケティング」を削除し、Authorize属性に新しいロール名を追加します... 健全な解決策とは言えません。この時点で、パーミッションベースのアクセスコントロールの必要性に気づくはずです。

パーミッションベースのアクセスコントロールとは、様々なユーザーや様々なロール、様々なクレームに様々なパーミッションを割り当て、実行時にコードからアクションを実行する許可をユーザーが持っているかどうかをチェックする方法である。もし、あるロールやクレームにパーミッションを割り当てたら、そのログインしたユーザーのロールやクレームが何であるかをチェックすることになる。そして、それらのロールやクレームに対してどのようなパーミッションが利用できるかをチェックすることになる。

このように、いくつかのパーミッションのセットを定義することができます。

"CanCreateCustomer、"CanDeleteCustomer、"CanEditCustomer、など。

さて、Actionメソッドをこのように装飾することができます。

[Authorize(Permission="CanCreateCustomer")]
public ActionResult CreateCustomer()
{
    return View();
}

Authorize(Permission="CanCreateCustomer")] がないことに注意してください。 MVCのクラスライブラリに組み込まれていないため、抽象的な意味での例として示しただけです。NuGetパッケージで、AuthorizeクラスにPermissionプロパティを持たせることも可能です。

さて、CreateCustomerアクションメソッドは常にCanCreateCustomer権限を必要とし、それは決して変化しないか、ほとんど変化しないことがおわかりいただけるでしょう。

誰がパーミッションを取得するのか？

一連のパーミッションを直接ユーザーに割り当てることができます。しかし、それはしないでください。管理するのがとてつもなく大変になります。むしろ、そうしてください。

Roleに一連の権限を割り当てることもできますし、Claimに一連の権限を割り当てることもできます(推奨)。

先ほども言いましたが、ロールもクレームと同じように考えることができます。ですから、ロールをクレームとして扱うことができます。そして、データベースにClaimsのテーブルを作成します。 そして、各クレームが複数のパーミッションを含むことができるリレーションシップを保持するための別のテーブルを作成します。

このセキュリティモデルは、クリーンなコードの実践を可能にします。さらに、アクションメソッドを書くとき、誰がこのメソッドを使えるかを考える必要はありません。むしろ、このメソッドを使う人は、管理者によって与えられた適切な許可を持っていることを常に保証することができます。そして、管理者は誰が何をできるようになるかを決めることができます。開発者であるあなたではありません。このように、ビジネスロジックとセキュリティロジックを分離することができます。

誰かがサインインするたびに、アプリケーションはそのユーザーに対して利用可能なすべての権限をチェックし、その権限セットは現在ログインしているユーザーの追加のプロパティとして利用できるようになります。要するに、パーミッション・ベースのアクセス制御を適用すれば、アプリケーションのセキュリティ・ロジックをよりコントロールできるようになるということです。

あなたのアプリケーションが、2つのロールしかないような非常に小さなアプリケーションである場合。顧客と管理者という2つの役割しかなく、顧客がアプリケーションで行うべきこと以外を行える可能性がないようなアプリケーションであれば、単純な役割ベースのアクセス制御で目的を果たすことができるかもしれませんが、アプリケーションが成長するにつれ、ある時点で権限ベースのアクセス制御の必要性を感じ始めるでしょう。