NRI OpenStandia (IAM編)Advent Calendar 2024

AuthZENとは

認可

Last updated at 2024-12-12Posted at 2024-12-12

はじめに

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

認可における課題

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

セキュリティ面の課題

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

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

OWASP TOP 10

OWASP TOP 10 API Security Risks

実装面の課題

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

① 従来の認可方式の限界

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

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

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

モダンな認可とは ?

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

	従来の認可	モダンな認可
内容	● 粗い (Coarse-grained) ● テナントレベルでの制御	● きめ細かい(Fine-grained) ● リソースレベルでの制御
制御方法	● アプリケーションに埋め込む	● ポリシーベース ● アプリケーションから独立
タイミング	● ログイン時に評価	● リアルタイム ● リソースにアクセスする直前
例	● OAuth	● OASIS XACML ● NIST SP 800-162 ● NIST SP 800-207

※ 上表は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とは ?

上記の背景をもとに発足した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のスコープ

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 1.0のInteropを触ってみる

こちらで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形式で記述されています。

PIP

{
  "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をたたきます。

evaluation API Request payload


{
  "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を返すようになっています。

evaluation API Response payload

{
  "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>]

evaluations API Request payload

{
  "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に準拠していくのか楽しみですね。

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

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up