「関係性」によるアクセス制御の可能性 Relationship-Based Access Controlとは？
5.8K Views
May 23, 24
スライド概要
2024/05/22に開催された「CloudNative Days Summer 2024 プレイベント@東京 (ハイブリッド開催)」で登壇させていただいた際のスライドです。
イベント詳細 - https://cloudnativedays.connpass.com/event/318627/
OpenFGA - https://openfga.dev/
Okta FGA - https://fga.dev/
Developer Advocate for Auth0 by Okta
関連スライド
各ページのテキスト
「関係性」によるアクセス制御の可能性: Relationship-Based Access Controlとは？
⾃⼰紹介 @Neri78
Okta Japan株式会社 Principal Developer Advocate 池原 ⼤然（Daizen Ikehara） Email: [email protected]
今⽇のお題 ● 開発者にとっての認可 ● ReBACとは？ ● OpenFGAを使ってみよう ● まとめ‧リソース
開発者にとっての認可
認証と認可 Authentication 認証 Authorization 認可 ユーザーが本人であることを確 認 ユーザーにリソースへの アクセスを許可 本人か？ このドキュメントにアクセスして編集す ることを許可できるか？
ロールを基にしたアクセス制御
● グループ/ロールに割り当てられたユーザー
● アプリケーション/APIレベルでの権限
app.get('/expense/approve',
claimIncludes('role', 'approver'),
(req, res) => { ... });
app.get('/expense/approve',
claimIncludes('permissions', 'approve:expenses'),
(req, res) => { ... });
属性を利用し、細かなアクセス制御 ● マネージャーは自分のチームの経費のみ承認できる
ポリシーエンジンを用いたアクセス制御 ポリシーエンジンを実装（ユーザーが経費の提出者のマネージャーかつ、承認の権限を持つか） アプリケーションからこのエンジンを呼び出し
ハードコードされた認可ロジックの課題 認可がどのように 動いているか不明 セキュリティ モジュール間で ⼀貫していない実装 プラットフォーム 監査ログの 不統合 新機能の追加が 困難 製品
ReBACとは？
ReBACとは ● ● Relationship-based Access Control (ReBAC) ○ リソースへのアクセス許可が「関係性」によって 決定されるアクセス制御 ○ 「このユーザーは、アクセスを可能にするほど、このオブジェクトや アクションと⼗分な関係があるか？」 ■ 関係性の⼀例 ● オブジェクトに関連する役割グループの⼀員である ● 直接関係がある ● ⽂章で共有されている 参考: Googleの様々な製品における認可エンジン “Zanzibar” IAM⼊⾨: 認可とは？ - https://auth0.com/jp/intro-to-iam/what-is-authorization Zanzibar: Google’s Consistent, Global Authorization System - https://research.google/pubs/zanzibar-googles-consistent-global-authorization-system/
https://zanzibar.academy/
基本
エディター‧ビューアー
グループ
フォルダー
他のアクセス制御⽅式との⽐較 粒度 認可 ロジック 認可 データ Role-based access control (RBAC) 粗い 集約 集約 Attribute-based access control (ABAC) 細かい アプリケーション コード アプリケーション データベース Policy-based access control (PBAC) 細かい 集約 アプリケーション データベース Relationship-based access control (ReBAC) 細かい 集約 集約 名前
ReBACを実装した OpenFGA
OpenFGAとは？ ● Cloud Native Computing Foundation (CNCF)で現在 “Sandbox maturity level”として採択されているオープンソースの認可ソリューションプロジェクト CNCF OpenFGA: https://www.cncf.io/projects/openfga/ Project Maturity Levels: https://www.cncf.io/project-metrics/
https://openfga.dev/
OpenFGAが提供するもの ● ReBACを適⽤した きめ細やかな認可（Fine-Grained Authorization - FGA）が 可能な認可エンジン（サーバー） ● 開発者向けツール ○ アプリケーション向けのSDK ■ Node.js/Javascript、GoLang、.NET、Python ● CLI ● Visual Studio Code Extension
OpenFGAサーバーのインストール ● ● ● 現在⽤意されているガイドは2つ (ローカルでも実行できる） ○ Docker ○ Kubernates ローカルでのセットアップ⽅法 ○ Homebrewを使⽤ brew install openfga ○ 事前コンパイルされたバイナリをダウンロード https://github.com/openfga/openfga/releases/tag/v1.4.2 サーバーの実⾏ ○ openfga run OpenFGA GitHub - https://github.com/openfga/openfga
CLIとVS Codeエクステンション CLI: 設定の⼊出⼒などをサポート VSCode Extension: シンタックスハイライト、テーマ、設定ファイルの変換、設定ファイルの検証 OpenFGA CLI - https://github.com/openfga/cli VSCode Extension - https://marketplace.visualstudio.com/items?itemName=openfga.openfga-vscode
Playground - モデルの定義やテスト
認可チェックまでの流れ ● 次の2つを⽤いて関係性を記述 ○ Authorization Model - 1つ以上のType Definitionの組み合わせ ■ 例: ユーザーとドキュメントが定義されている ● ドキュメントは次の関係性を持つ ○ ○ ● 閲覧者 [ユーザー]、編集者 [ユーザー]、オーナー[ユーザー] Relationship Tuple - 関係性を表す構⽂、動的に変わりうる ■ 例:ユーザーのdaizenはドキュメントのスライドに対して 編集者という関係を有する OpenFGAサーバーに対して関係性の確認をリクエストする ○ Q: ユーザー:daizenはドキュメント:スライドに対して閲覧者という関係が あるか？
Authorization Modelの作成 ● 1個以上のType Definitionを定義 ○ Type Definitionには Relation Definitionが含まれる model schema 1.1 type user ● Type Definition 例: ユーザーとドキュメントを定義 ○ ドキュメントは次の関係性を持つ ■ 閲覧者 [ユーザー] ■ 編集者 [ユーザー] ■ オーナー[ユーザー] type document relations define viewer: [user] define editor: [user] define owner: [user] Relation Definition
Configuration Language - DSL or JSON
APIのリクエストにはJSONを使⽤する
model
{
"owner": {
"editor": {
"this": {}
"directly_related_user_types": [
"schema_version": "1.1",
schema 1.1
"type_definitions": [
}
{
},
relations
define viewer: [user]
define editor: [user]
define owner: [user]
"type": "user"
"type": "user",
"metadata": {
"relations": {},
"relations": {
]
"metadata": null
"viewer": {
},
},
"directly_related_user_types": [
"owner": {
type user
type document
{
{
}
{
"type": "document",
"directly_related_user_types": [
"type": "user"
"relations": {
{
}
"viewer": {
]
"this": {}
},
"type": "user"
}
]
},
}
"editor": {
}
"this": {}
}
},
}
]
FGA CLIで相互の変換が可能 - https://github.com/openfga/cli/
}
Relationship Tuple 例:ユーザーのdaizenはドキュメントのスライドに対して編集者という関係を有する user、relation、object、condition ● user - objectと関係を有する エンティティ ○ user: daizen ● object - システムに存在する エンティティ ○ document:slide ● relation - 関係 ○ editor ● condition - 条件（任意） ○ in_allowed_ip_range [{ "user": "user:daizen", "relation": "editor", "object": "document:slide" }]
Check ユーザー:daizenはドキュメント:スライドに対して閲覧者という関係があるか？
SDK - Storeの作成
npm install @openfga/sdk
import { OpenFgaClient } from '@openfga/sdk';
import 'dotenv/config';
// クライアントの初期化
let fgaClient = new OpenFgaClient({
apiScheme: process.env.FGA_API_SCHEME,
apiHost: process.env.FGA_API_HOST
});
// Storeの作成
console.log('Storeの作成...');
const { id: storeId } = await fgaClient.createStore({
name: "cnds2024",
});
console.log(`Store ID: ${storeId}`);
SDK - Authorization Modelの作成
// クライアントの初期化
// Authorization Modelの作成
let fgaClient = new OpenFgaClient({
console.log('Authorization Modelの作成...');
apiScheme: process.env.FGA_API_SCHEME,
const { authorization_model_id:
apiHost: process.env.FGA_API_HOST,
authorization_model_id } =
storeId: process.env.FGA_STORE_ID
await fgaClient.writeAuthorizationModel({
"schema_version": "1.1",
});
"type_definitions": [
{
"type": "user",
"relations": {},
"metadata": null
},
// … 省略
]
}
);
SDK - Relationship Tupleの追加
// クライアントの初期化
// Relation Tupleの追加
let fgaClient = new OpenFgaClient({
// ユーザーの daizenはドキュメントのスライドに対して編集者という
apiScheme: process.env.FGA_API_SCHEME,
関係を有する
apiHost: process.env.FGA_API_HOST,
console.log('Relation Tupleの書き込み ...');
storeId: process.env.FGA_STORE_ID,
authorizationModelId:
const { result
} = await fgaClient.write({
writes: [
process.env.FGA_FGA_AUTHORIZATION_MODEL_ID
{"user":"user:daizen",
});
"relation":"editor",
"object":"document:slide"}],
},
{
authorization_model_id:
process.env.FGA_FGA_AUTHORIZATION_MODEL_ID
});
SDK - Check
// クライアントの初期化
// チェック
let fgaClient = new OpenFgaClient({
apiScheme: process.env.FGA_API_SCHEME,
apiHost: process.env.FGA_API_HOST,
storeId: process.env.FGA_STORE_ID,
console.log('チェック...')
let { allowed } = await fgaClient.check({
user: 'user:daizen',
authorizationModelId:
process.env.FGA_FGA_AUTHORIZATION_MODEL_ID
relation: 'viewer',
});
object: 'document:slide',
});
console.log(`user:daizenはdocument:slideの閲
覧権限を持っている = ${allowed}`);
ownerが編集‧閲覧権限を持つには？ model model schema 1.1 schema 1.1 type user type user type document type document relations relations define viewer: [user] define viewer: [user] or editor define editor: [user] define editor: [user] or owner define owner: [user] define owner: [user]
ReBACの利⽤が適しているかどうか？ ● ● 考慮すべきと感じた点 ○ 権限のモデルを把握できているか（ドキュメント、フォルダ...あと必要なものは？） ○ オブジェクトやユーザーに対して権限設定、共有設定の追加、更新、削除の頻度は？ 実運用に適しているか？ ○ チェックは「常に」⾏われる ■ レスポンスタイムやスケーラビリティ ■ エンドポイントのセキュリティ
まとめ‧リソース
まとめ‧リソース ● 「関係性」を⽤いることでより細かなアクセス制御が可能 ○ 利⽤シナリオの検討が必要 ○ Authorization Modelの設計がとても重要に感じる ● OpenFGA - https://openfga.dev/ ● Okta FGA (Authorization as a Service) - https://fga.dev/
認証‧認可機能を実装するなら Customer Identity Cloud（Powered by Auth0） https://a0.to/jp-cic-dev
Thank you! @Neri78