現在のアプリケーションやシステムの構築において「認可」は欠かせない非常に重要な要素です。しかし、その実装はしばしば複雑で、様々な課題を抱えることがあります。そのような課題を解決するべく、2023年OpenID Foundation内にAuthZENワーキンググループが発足しました。そこで、アドベントカレンダー企画の認可分野の最終日は、AuthZENについて、その概要や特徴、動向について紹介していきたいと思います。

認可は、リソースへのアクセス権限を制御する重要な仕組みですが、セキュリティ面および実装面の課題が顕著となっています。

セキュリティ面の課題

認可のセキュリティリスクは、OWASP^[1]（Open Web Application Security Project）が発表する「OWASP Top 10」や「OWASP API Security Top 10」においても深刻な課題として取り上げられています。これらのレポートでは、認可に関するトピックが複数あり、認可の脆弱性が攻撃の大きなターゲットであり、セキュリティ上の重要な課題であることがわかります。

認可に関するセキュリティリスクとして以下がランクインしています。

OWASP TOP 10

• A01:2021 – Broken Access Control
• A04:2021 – Insecure Design
• A05:2021 – Security Misconfiguration
• A07:2021 – Identification and Authentication Failures
• A09:2021 – Security Logging and Monitoring Failures

OWASP TOP 10 API Security Risks

• API1:2023 - Broken Object Level Authorization
• API3:2023 Broken Object Property Level Authorizatio
• API5:2023 Broken Function Level Authorization

実装面の課題

実装面においては以下の課題があります。

① 従来の認可方式の限界

OAuthは多くのアプリケーションで利用されていますが、そのトークン管理では、きめ細かな認可制御や動的なルール適用が難しいケースがあります。特に、高頻度で変化するリアルタイムのアクセス制限や対応においては、実装が難しく課題となります。

② アプリケーションに依存する権限管理

現在多くのシステムにおいて、各アプリケーションが独自の方法でユーザーの権限を管理しているため、システム全体の複雑性が増大します。つまり、複数のアプリケーションがデータソースごとにそれぞれ認可ポリシーを設定する必要があり、無駄とコストが発生します。また、認可判断ロジックの実装不備が重大な脆弱性を引き起こす可能性があります。事実、この脆弱性については上記のOWASPのセキュリティリスクでも言及されています。

上記のような課題を解決すべく「モダンな認可^[2]」という考え方が注目されています。モダンな認可ではアプリ内での認可判断を外部化した認可サービスに問い合わせ、認可ポリシーやリクエスト情報などをもとに認可判断を実施します。これにより、セキュリティポリシーの統一管理が可能になります。また、リアルタイムで動作し、ポリシーに基づいてきめ細かい制御を行うため、ゼロトラストアーキテクチャやマイクロサービス環境に適しています。

※上表はKubeCon NA (November 2024)のスライドを参考

モダンな認可は、Policy Enforcement Point (PEP) と Policy Decision Point (PDP) という基本的なアーキテクチャに基づいています。このモデル自体は古くから存在していますが、近年の技術進化により、実用性が飛躍的に向上しました。

このPEP/PDPモデルについてNIST SP 800-207の「ゼロトラストの中核となる論理コンポーネント」を参考に簡単に説明します。

システムがある企業リソースにアクセスしようとしてる場面を考えます。

まず、システムはPEP（Policy Enforcement Point）にアクセスリクエストを送信します。PEPはリクエストを受け取ると、そのリクエストをPDP（Policy Decision Point）に送信して評価を求めます。PDPは、リクエストが許可されるべきか、拒否されるべきかを判断します。PDPはその評価結果をPEPに返し、PEPはリソースへのアクセスを許可するか拒否するかを決定します。

このアーキテクチャについては、2024年12月4日に開催された「CNCJ: Cloud Native Security Japan LT祭り」にて、NRI社員がアプリケーションレイヤ認可の動向とアーキテクチャというテーマでプレゼンテーションを行っていますので、是非ご参考にしていただければと思います。

上記の背景をもとに発足したAuthZENワーキンググループは、動的できめ細かい認可スキームの実装性、拡張性、相互運用性を改善する方法を探求することを目的に「モダンな認可」を実現するアーキテクチャの標準化活動を行っています。

The purpose of this WG is to explore how to improve the deployability, scalability and interoperability of dynamic, fine-grained authorization schemes to better meet the needs of modern information security best practices.

※公式より抜粋

AuthZEN – Charter - OpenID Foundation

AuthZENのスコープ

AuthZENは「認証分野のOAuth2/OIDC/SAMLのような認可のスタンダードとなること」を目指しています。具体的には、AuthZENのスコープは以下の通りになっています。

• 既存の認可方式や標準規格（ALFA、Cedar、OPA、IDQL、OpenFGA、Topaz、SpiceDBなど）間の相互運用性を向上させる
• 主要な認可コンポーネント（PAP、PDP、PEP、PIPなど）間の互運用可能な通信パターンを定義・形式化する
• 外部化された認可を推奨されるパターンとして確立・促進する

現在までの取り組み

PEPとPDP間のAPI標準化を目的とした「Authorization API 1.0 – draft 01」が2024年11月にOpenID Foundationのメンバーシップによって承認されました。このAPIはevaluation APIとして定義され、PEPとPDPが互いの内部構造を理解することなく、認可リクエストと判断レスポンスをやり取りできることを可能にします。これにより、アプリケーションに変更を加えることなく外部の認可機能を統合できるようになります。

2024年12月現在、最新の「Authorization API 1.1 – draft 01」では、複数の評価依頼を一括で処理できる「boxcarring」機能が「evaluations API」として追加されており、現在進行中となっています。

こちらでAuthZENのInteropが公開されていたので、触ってみました。

Introduction | OpenID AuthZEN Interop

「Interop」という言葉は、「Interoperability」（相互運用性）の略で、一般的に異なるシステムが、円滑に連携し合い機能する能力を指します。本Interopでは、様々なPDPに対してevaluation APIを用いて、シンプルなTodoアプリケーションを例にその相互運用性を試すことができます。Todoアプリケーションの詳細な内容は本記事の趣旨から外れるため割愛しますが、簡単に言えば、異なるロールを持つ複数のユーザーが共同で利用するTodoサービスです。

構成

このInteropは以下のコンポーネントで構成されています。

• Todoリストを管理するReactベースのフロントエンド
• PEPとして動作するNode.jsのバックエンド
• バックエンドがAuthZEN APIを通じて呼び出す任意のPDP

リクエストとレスポンス

PEPは、リクエストペイロードに必要な情報を載せてPDPに通信を送ります。その後、PDPはPIP（Policy Information Point）から取得した情報を基に認可判断を行い、判断結果をPEPにレスポンスとして返します。

PIPはTodoアプリを使用するユーザの属性(idや名前など)がJSON形式で記述されています。

{
  "CiRmZDA2MTRkMy1jMzlhLTQ3ODEtYjdiZC04Yjk2ZjVhNTEwMGQSBWxvY2Fs": {
    "id": "rick@the-citadel.com",
    "name": "Rick Sanchez",
    "email": "rick@the-citadel.com",
    "roles": ["admin", "evil_genius"],
    "picture": "https://www.topaz.sh/assets/templates/citadel/img/Rick%20Sanchez.jpg"
  },
  "CiRmZDM2MTRkMy1jMzlhLTQ3ODEtYjdiZC04Yjk2ZjVhNTEwMGQSBWxvY2Fs": {
    "id": "beth@the-smiths.com",
    "name": "Beth Smith",
    "email": "beth@the-smiths.com",
    "roles": ["viewer"],
    "picture": "https://www.topaz.sh/assets/templates/citadel/img/Beth%20Smith.jpg"
  },

  (略)
  
}

AuthZEN1.0のInteropでは複数のリクエストが実装されていますが、一例としてGET /todosを説明します。アプリケーション(PEP)は以下のような形式でペイロードを作成して、evaluation APIをたたきます。

{
  "subject": {
    "type": "user",
    "id": "<subject_from_jwt>"
  },
  "action": {
    "name": "can_read_user"
  },
  "resource": {
    "type": "user",
    "id": "<email_OR_subject>"
  },
  "context": {
  }
}

<subject_from_jwt>は各リクエストのAuthorizationヘッダーのBearerトークンから取り出します。

PDPはPIPを参照して、認可判断を下し、レスポンスペイロードを作成します。許可する場合は"decision": trueを返し、"decision": falseを返しますが、GET /todosではすべてtrueを返すようになっています。

{
  "decision": true
}

また、本記事では省略しますが、GET以外にもInteropでは POSTやPUT、DELETE等のケースも試すことができ、trueだけでなくfalseも返します。

AuthZEN 1.1 では evaluations APIが実装されており、複数の評価依頼を一括で処理できるいわゆる、「boxcarring」が可能となっています。

POST /access/v1/evaluations HTTP/1.1
Host: mypdp.com
[Authorization: Bearer <token>]

{
  "subject": {
    "type": "user",
    "id": "<subject_from_jwt>"
  },
  "action": {
    "name": "can_update_todo"
  },
  "resource": {
  },
  "context": {
  },
  "evaluations": [
    {
      "resource": { 
        "type": "todo",
        "id": "<uuid-of-the-todo>",
        "properties": {
          "ownerID": "<email_of_owner>"
        }
      }
    },
    {
      "resource": {
        "type": "todo",
        "id": "<uuid-of-the-todo>",
        "properties": {
          "ownerID": "<email_of_owner>"
        }
      }
    }
  ]
}

レスポンスペイロードの例は、以下の通りです。

{
  "evaluations": [
    {
      "decision": false
    },
    {
      "decision": true
    }
  ]
}

AuthZEN Interopはplaygroundが用意されており、任意のPDPに対してevaluation APIのリクエストとレスポンスを試すことができます。

TopazをPDPとして利用した場合は、

リクエストを任意の値に設定し、

リクエストペイロードを

として「Execute」を実行すると

のようにTopazの認可判断が適応され、レスポンスが返ってきます。
このほかにも様々な条件を試すことができるため、是非自分の手で触って遊んでみて下さい。

また、このToDoアプリケーションにはデモの用意されているため以下のこちらからぜひ試してみてください。

Email Address : beth@the-smiths.com
Password : V@erySecre#t123!

等でログインすることができます。

AuthZEN 1.0 のInteropでは、Topazを含めた多くのOSSや商用プロダクト、サービスに対応しています。以下が2024年12月8日現在の対応済みのサービスです。

• Aserto
• Cerbos
• Open Policy Agent
• Topaz
• Hexa
• PingAuthorize
• Kogito
• PlainID
• SGNL
• Axiomatics
• Indykite
• EmpowerID

今後どのようなサービスがAuthZENに準拠していくのか楽しみですね。

2024年11月に開催されたKubeCon NAのプレゼンテーションによると、Future Workとして、サブジェクトがアクセス可能なすべてのリソースを検索するための Resource Search APIと、特定のリソースにアクセス可能なすべてのサブジェクトを検索するためのSubject Search APIの開発が進められているとのことです。

さらに、以下の取り組みも進行中です。

• リライングパーティー（Workday、SFDCなど）との連携による認可の外部化
• APIゲートウェイベンダーと連携し、AuthZENを自社製品に組み込む
• Interopの運用シナリオの追加
• 実装の追加 (特に ReBAC システム)
• PDP/PIPへのポリシー検出/管理
• イベントでの発信

本記事では、認可の課題やモダンな認可の重要性、そしてAuthZENの概要とその実際の利用について紹介しました。AuthZENは、柔軟でセキュアな認可の管理を提供し、特に分散型システムにおける複雑なポリシー管理を簡易化、効率化します。Interopを実際に試してみることで、その仕組みを体験でき、今後ますます注目される技術であることが実感できました。

認可の進化に伴い、システムのセキュリティやユーザーのプライバシーを守りながら、より精緻で柔軟な権限管理が求められる中で、AuthZENは今後ますます重要な役割を果たすと考えています。今後のアップデートや新しい機能にも注目し、また、実際のプロジェクトに活用していきたいですね。

OWASP Top 10ってなに？ - 株式会社セキュアイノベーション

AuthZEN Working Group - OpenID Foundation

• [1] OWASPは、ソフトウェアのセキュリティ向上を目的とする非営利財団であり、WebアプリケーションやAPIに関連する脆弱性や攻撃手法を分析し、その中でも特に危険性の高い項目を定期的にレポートにまとめています。
• [2] 「モダンな認可」は公式なネーミングではありませんが、海外カンファレンスなどでもこのように表現されることがあるので、本記事でも「モダンな認可」と表現しています。