はじめに

みなさん「タコス」食べていますか？

こんにちは、tacosDB 開発責任者です。

タコスが好きすぎてタコスに特化したサイト「tacos DB」を開発しています！

tacos DB では、WordPress などは使用しておらず、タコスのお店や記事を管理するための CMS をフルスクラッチで作っています。

CMS があると、誰が、何を、どこまで操作できるようにするかが課題として挙がりがちです

そして最近は、もうひとつ考えることが増えました

「AI に作業をお願いするとき、どこまで権限を渡す？」

tacos DB は運営メンバーが少ないため

AI に記事を書いてもらう
AI に店舗情報を補完してもらう
AI に CMS 入稿を手伝ってもらう

様々な作業を AI に手伝ってもらっています。

でも、記事を書くだけの AI に全ての操作権限を渡すのは、だいぶ怖いですよね？

この記事では、下記のことをまとめていこうと思います。

認証と認可
ACL / RBAC / ABAC / ReBAC / PBAC といった認可モデル

ちなみに、tacos DB では、「endpoint を叩けるか」は RBAC + scope で管理し、「その対象を本当に操作してよいか」は usecase の domain rule で弾いています。

認証と認可

認証と認可は別物です。

ログインして「あなたは member_123 です」と確認するのが認証。

その member_123 が何をしてよいかを確認するのが認可です。

認証と認可についてはわかりやすく説明してくれている記事がたくさんあるのでそちらをご参照ください！

認可モデルいろいろ

認可モデルにはいくつか種類があります。

認可モデル	考え方	向いている場面	注意点
ACL	人と操作を直接つなぐ	小さいシステム、操作単位で細かく許可したい場合	人や操作が増えると管理がつらい
RBAC	role で管理する	管理画面、CMS、社内ツール	role が増えすぎると複雑になる
ABAC	属性で判定する	ユーザー状態、リソース状態、時間、地域などを条件にしたい場合	条件が増えると、どこで何を判定しているか追いにくい
ReBAC	関係性で判定する	Google Drive 的な共有、チーム、組織、親子関係のあるリソース	強力だが、設計と実装が重くなりやすい
PBAC	policy として判定する	RBAC / ABAC / ReBAC を整理して扱いたい場合	policy の置き場所や責務を決めないと散らかる

ACL: Access Control List

ACL は Access Control List の略です。

「この人はこの操作ができる」という表を持つ方式です。

MemberA は店舗の作成ができる
MemberA は店舗の更新ができる
MemberB は店舗の公開ができる
MemberC は記事の作成ができる

みたいな感じですね
ただし、ユーザーや操作が増えると、表がどんどん大きくなります。

機能やメンバーが少ないうちはいいですが増えてくると大変です。

RBAC: Role-Based Access Control

RBAC は Role-Based Access Control の略です。

人に直接権限を付けるのではなく、role に権限を持たせます。

新しい編集者が増えたら、その人に ShopSubmitter role を付ける。

tacos DB でも、member と role は member_role を介して紐づきます。
1 人の member が複数 role を持てる方針です。

ACLよりは管理しやすいですが、やはりロールが増えると管理が大変になるでしょう。

ABAC: Attribute-Based Access Control

ABAC は Attribute-Based Access Control の略です。

ユーザーやリソースの属性を見て判定します。

たとえば、こういう判定です。

member.team が editor で、shop.status が draft なら操作できる

便利ですが、気を抜くと「結局どこで何を判定してるんだっけ？」になります。

ReBAC: Relationship-Based Access Control

ReBAC は Relationship-Based Access Control の略です。

ユーザーとリソースの関係性を見て判定します。

Google Drive のような「フォルダに権限があって、その配下のファイルにも継承される」イメージが近いです。

強力ですが、実装は重くなりがちです。

小さめの CMS でいきなり ReBAC をフル実装すると、管理に無駄にコストがかかってしまいます。

PBAC: Policy-Based Access Control

PBAC は Policy-Based Access Control の略です。

policy に基づいて「許可するかどうか」を決める考え方です。

PBAC は、RBAC / ABAC / ReBAC と完全に別物というより、それらを policy として整理する考え方に近いです。

tacos DB の認証認可

tacos DB では、role のアクセス範囲を role_access_scope.method と role_access_scope.path_pattern で保持しています。
CMS endpoint の HTTP method と path 文字列で制御する方針です。

ER 図にするとこうです。

認可処理では、request の method と path を正規化し、member id から access scopes を取得します。
そして、method pattern と path pattern の両方が一致すれば許可します。

AI作業員に権限を与える

ここまでやると、AI 作業員にも権限を渡しやすくなります。

記事を書く AI には writer。
店舗情報を入稿する AI には submitter。
公開設定を見る AI には maintainer。

プロンプトで「これはやらないで」と言うのも大事です。

その上で、AI が多少雑に動いても、権限がなければ endpoint を叩けません。
endpoint を叩けても、domain rule に反していれば usecase で止まります！

これで安心してAIに作業してもらえますね！

まとめ

認証と認可は異なり、認可モデルには、ACL / RBAC / ABAC / ReBAC / PBAC があります。

tacos DB では、RBAC を基本にしつつ、HTTP method + endpoint path pattern で scope を管理しています。

さらに、 endpoint を叩けるか と その対象を操作してよいか を分けています。

AI に何でも頼める時代だからこそ、AI に何でもできる権限を渡さず、今まで通り最小権限の原則に従いましょう！

リリースした tacos DB は、まだ掲載店舗数を増やしている途中です。

店舗情報、写真、紹介文を提供してくれる方や、タコスが好きで一緒に整えてくれる方を募集しています。

知っているお店があれば、ぜひお問い合わせフォームから投稿してください。