## 背景 [前の記事](/ciam-101-intro-authn-sso/)で、認証（AuthN）と承認（AuthZ）の概念、およびいくつかの頭痛を引き起こす用語：Identity、Organization、Tenantなどを紹介しました。組織とテナントは、アイデンティティをグループ化するのに便利ですが、完全な民主主義をもたらします：このシステムではすべての人がすべてを行うことができます。ユートピアがまだ謎のままなので、アクセスのガバナンス、つまり承認（AuthZ）を見てみましょう。 ### なぜ私たちは承認が必要なのでしょうか？承認（AuthZ）は、「あなたは何ができますか？」という質問に答えます。 Notionは素晴らしい例です。所有している各ページについて、プライベートに保つ、つまり自分だけがアクセスできるようにするか、友人と共有するか、あるいは公開するかを選択できます。また、オンライン書店の場合、すべての人がすべての本を表示できるようにしたいが、顧客は自分の注文だけを表示し、売り手は自分の店の本だけを管理するようにしたいと思います。 AuthZとAuthNは、複雑なビジネスモデルの必須コンポーネントです。これらは通常、一緒に行われます。 AuthZはユーザーのアクセスを確認し、AuthNはアイデンティティを認証します。どちらも安全なシステムには必要です。 ## 基本的な権限付与モデル最も一般的なAuthZモデルの1つを紹介します：**IDENTITY**が**ACTION**を**RESOURCE**上で実行する場合、**ACCEPT**または**DENY**です。例えばNotionの場合、モデルは下記の通りです。「**PERSON**が**PAGE**上で**VIEW**を行います」。ページがプライベートの場合、次のようになります: - **PAGE**上で**VIEW**を行った場合、**ACCEPT**を受け取ります。 - その他のすべての人は、あなたの**PAGE**上で**VIEW**を行ったときに**DENY**を受け取るはずです。業界のコンセンサスに基づいて、承認技術が幅広く開発されました。例えばロールベースのアクセス制御（RBAC）、属性ベースのアクセス制御（ABAC）などです。今日は、[NIST RBACモデル](https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf)のLevel 1：Flat RBACに焦点を当てます。 ## ロールベースのアクセス制御 NIST RBACモデルは、さまざまなシナリオに対する柔軟性と適応性を提供するために多くのことを開放しています。Logtoは現在、追加の概念「リソース」（すなわち、API リソース）を持つLevel 1の定義を採用しています。書店の例を拡張してみましょう。たくさんの顧客がいるとしますが、売り手は1人だけです。 - 顧客は、本を閲覧し注文することができ、また自身の注文を閲覧することもできます。 - 売り手は、本を閲覧し、作成し、削除し、顧客の注文を管理できます。 ### リソースの定義 Logtoでは、リソース（つまりAPIリソース）は通常、エンティティやアイテムのセットを表します。これは、その指標として有効なURLを使用する必要があるからです。したがって、次の二つのリソースを定義します： - 本：`https://api.bookstore.io/books` - 注文：`https://api.bookstore.io/orders` URL形式を強制する1つの利点は、それがあなたのAPIサービスの実際のアドレスにマッピングできることです。これにより、システムの他のコンポーネントと統合する際の読みやすさと認識能力が向上します。 🤔 リソースはビジネスのニーズに応じて分ける必要があります。ワンサイズフィットオールのアプローチはありません。決定はケースバイケースでなければなりません。本と注文を分けるこの記事の例は、マイクロサービスには適していますが、モノリシックなアーキテクチャには適していません。 ### 権限の定義リソースの概念を導入したので、Logtoでは、権限はリソースに属しなければならないと規定しています。逆に、リソースには権限を設けることができます。リソースにいくつかの権限を追加しましょう： - 本：`read`、`create`、`delete` - 注文：`read`、`read:self`、`create:self`、`delete` 許可の名前に要件はありませんが、以下の規則があります： ``` [:] ``` ここで``は許可を説明するために必要であり、`:`は一般的な対象を説明するために無視できます。つまり、リソース内のすべてのエンティティやアイテムに対するものです。例えば： - リソースBooksの許可`read`は、任意の本を読むアクションを意味します。 - リソースOrders内の `create:self`許可は、現在のユーザーが所属する注文を作成するアクションを意味します。 ### ロールの定義簡単に言えば、ロールは一連の権限のグループです。 `customer`と`seller`という二つのロールを作成し、それらに以下のように権限を割り当ててみましょう： ```mermaid erDiagram Role-Customer { permission Books "read" permission Orders "read:self" permission Orders "create:self" } Role-Seller { permission Books "read" permission Books "create" permission Books "delete" permission Orders "read" permission Orders "delete" } ``` 許可-ロールの割り当ては多対多の関係です。 ### ユーザーにロールを割り当てるロール-許可の割り当てと同様に、ユーザー-ロールの割り当ても多対多の関係です。したがって、1つのユーザーに複数のロールを割り当てることができ、1つのロールを複数のユーザーに割り当てることができます。 ### つなげる以下は、LogtoのLevel 1 RBACモデルの完全な関係図です： ```mermaid erDiagram User }|--|{ Role : maps Role }|--|{ Permission : maps "API Resource" ||--|{ Permission : contains ``` RBACモデルでは、許可は常に「正」です。つまり、承認の判断はシンプルです：ユーザーが許可を持っていれば、受け入れます。そうでなければ、拒否します。 Aliceが`seller`のロールを持ち、BobとCarolが`customer`のロールを持っているとします。まず、自然言語でアクションを説明し、それらを標準的な承認形式に変換します：**IDENTITY**が**ACTION**を**RESOURCE**上で行いますし、最終的な結論を出します。 - Aliceが新しい本を発売したい。 - ユーザーAliceがBooks（`https://api.bookstore.io/books`）というリソース上で`create`を実行します。 - Aliceが`seller`の役割によってBooksの`create`権限が割り当てられているので、結果は✅ **ACCEPT**です。 - Aliceが売上が期待通りであるかを確認するためにすべての注文を表示したい。 - ユーザーAliceがOrders（`https://api.bookstore.io/orders`）というリソース上で`read`を実行します。 - Aliceが`seller`の役割によりOrdersの`read`権限が割り当てられているため、結果は✅ **ACCEPT**です。 - Bobが購入したい本があるかどうかを確認するために、本のリストを参照したい。 - ユーザーBobがBooks（`https://api.bookstore.io/books`）というリソース上で`read`を実行します。 - Bobが`customer`の役割によりBooksの`read`権限が割り当てられているため、結果は✅ **ACCEPT**です。 - BobがCarolの注文を見たい。 - 誰か他の人の注文なので、`Orders`の`read:self`許可はここでは機能しません。 - ユーザーBobがOrders（`https://api.bookstore.io/order`）というリソース上で`read`を実行します。 - BobはOrdersの`read`権限を持っていないので、結果は❌ **DENY**です。 ### 他のRBACレベル NIST RBACモデルには4つのレベルがあります： - Flat RBAC - Hierarchical RBAC - Constrained RBAC - Symmetric RBAC 興味がある場合は、詳細について[paper](https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf)をご覧ください。 Logtoは現在、Level 1の実装を提供しており、コミュニティからのフィードバックに基づいて高いレベルに進行する予定です。もし高いレベルがあなたのニーズに適していると思われる場合は、遠慮せずにお知らせください！ ## 実際には理論だけでなく、予想通りの動作をさせるために完了させる必要がある大量の技術作業もまだあります： - クライアントと認証サーバーの開発 - RBACのためのデータベース設計 - 異なるサービス間の検証 - セキュリティとオープンスタンダードの準拠 - ロール、権限、リソースの管理と割り当てパニックにならないでください。これを考慮に入れて、すべてをカバーするための即時サポートを追加しました。 RBACをLogtoで使用する方法については[🔐 RBAC recipe](https://docs.logto.io/docs/recipes/rbac/)をご覧ください。 ## 最後に RBACは、ほとんどの場合の強力なアクセス管理モデルですが、万能薬はありません。まだいくつかの質問があります： - 高いレベルのRBACが必要ですか？ - RBACは他の承認モデルとどのように比較されますか？ - 異なる組織間の承認モデルをどのように定義しますか？ 🔥 お見逃しなく。 CIAM 103でお会いしましょう！