FC Tokyo2025 フロントエンドで実現するアクセス制御入門

Transcript

1. フ ロ ン ト エ ン ド で 実 現 す る ア ク セ ス 制 御 入 門 フロントエンドカンファレンス東京2025 EC-9624(@e_chanoknan)
2. 自己紹介 Eakudompong Chanoknan エークドッムポン　チャノックナン 株式会社 PRTIMES 2025年新卒 主にフロントエンド領域を担当しています。 X:@e_chanoknan タイ・バンコク出身
3. Agenda アクセス制御とは？ 01. アクセス制御モデル RBAC VS ABAC 02. CASLで実装するABAC 03. Policy-as-Code 04. まとめ 05.
4. アクセス制御とは？
5. あなたは誰ですか？ Who are you? あなたは何を許可されていますか？ What are you allowed to do?
6. アクセス制御 誰が・どのリソースに・何ができるかを定義する 主な2つの役割： 認証(Authentication) — あなたが誰であるかの確認 認可(Authorization) — 何を行う権限があるかの確認 アクセス制御モデル: Role-base access control Attribute-Based Access Control
7. Role-Based Access Control
8. RBAC RBAC (Role-Based Access Control) アクセス判断は、ユーザーに割り当てられたロールに基づいて行われる。 ユーザーはロール（例：‘admin’、‘manager’、‘employee’）を通じて 権限を得る。 例: managerのロールは従業員記録にアクセスできる。 adminのロールは給与データにアクセスできる。 メリット: 実装が容易 デメリット: 柔軟性に欠ける 制御が複雑になるとがロール急増してしまう
9. Attribute-Based Access Control
10. ABAC ABAC (Attribute-Based Access Control) アクセス判定はユーザー（主体） 、リソース（対象） 、アクション、環境の 属性に基づいて行われます。 例: ユーザー: ロール, 部署, 位置情報 アクション: 作成、編集、削除 リソース: カテゴリ, オーナー 環境: 時間、デバイス、ネットワーク メリット 柔軟・細粒度・コンテキストに応じたルールが可能。 デメリット 設計と保守がより複雑になります。
11. OWASP のガイダンス OWASP Authorization Cheat Sheet は、単純な RBAC の限界を指摘。 より柔軟で安全な ABAC/リレーションシップベースのモデルを推奨。 以降のフロントエンド例でRBACの限界を説明します。 RBAC VS ABAC
12. Requirments: Admin すべてを管理可能。 Editor 新規ブログを作成とブログ編集できますが、ブログを削除できない。 例：ブログ配信サービス
13. 要件を最初に見たとき、おそらくこんな感じでやると思います。 でも、このやり方だと、新しいロールが追加されたり権限が変更されたりす るたびに、チェックを行っている箇所をすべて修正しなければならないとい う問題があります
15. ロールや権限が追加する場合 このファイルのみを編集する。
17. ここで要件が変更され、より強力なアクセス制御を適用したいと考えます。 要件: 管理者（Admin） ：すべてを管理できる 編集者（Editor） ：割り当てられたカテゴリー内で自分のポストを編集・ 削除できるが、公開済みの投稿は削除できない この要件は少し複雑なので、モデルを ABAC に変更し、実装には CASL とい うライブラリを使用します。 例：ブログ配信サービス
18. CASLはフロントエンドで ABACスタイルのチェックを実装できる。
20. フロントエンドの責務: ユーザーが実行できない操作を示すUI要素を表示しない Fail-fastなUX: ボタンを非表示／無効化する、ルートをガードする セキュリティにはならない。 認可は必ず サーバー側 で強制すること フロントエンドだけのチェックの限界
21. スケーリングの問題 バックエンドとフロントエンドも権限を統一しなければならない。 システムがない場合: フロントとバックで権限ロジックが重複。 同期が難しい。 新しいロールや権限を追加するたびにコードを複数箇所編集。 解決策: Policy-as-Code 権限ロジックを宣言的ファイル（YAML/JSON）に保存。 共通エンジン（CEL など）で評価。 ソースコードとして管理
22. リーソース アクション Cel evaluator で評価
23. ポイント: condition は CEL で評価。 同じポリシーファイルをバックエンドでもフロントエンドでも利用可能。(Single Source of truth) バックエンドが強制、フロントエンドは UI 表示用に消費。 POLICY AS CODE
24. まとめ RBAC はシンプルだが限界あり。 ABAC（OWASP 推奨）は柔軟で強力。 CASL でフロントエンドでも ABAC を実現可能だが、サーバー側での enforcement は必須。 Policy-as-Code でスケールし、Single Source of truthを実現。 フロントとバックで同じルールを使うことで、一貫性と保守性が向上。
25. 参照 https://casl.js.org/v6/en/guide/intro https://cheatsheetseries.owasp.org/cheatsheets/Authorizati on_Cheat_Sheet.html https://github.com/WebDevSimplified/permission-system/ https://www.reactmiami.com/speakers/prasad
26. ご清聴ありがとうございました!