「関係性」によるアクセス制御の可能性 Relationship-Based Access Controlとは?

4.9K 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/

profile-image

Developer Advocate for Auth0 by Okta

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

(ダウンロード不可)

関連スライド

各ページのテキスト
1.

「関係性」によるアクセス制御の可能性: Relationship-Based Access Controlとは?

2.

⾃⼰紹介 @Neri78

3.

Okta Japan株式会社 Principal Developer Advocate 池原 ⼤然(Daizen Ikehara) Email: [email protected]

5.

今⽇のお題 ● 開発者にとっての認可 ● ReBACとは? ● OpenFGAを使ってみよう ● まとめ‧リソース

6.

開発者にとっての認可

7.

認証と認可 Authentication 認証 Authorization 認可 ユーザーが本人であることを確 認 ユーザーにリソースへの アクセスを許可 本人か? このドキュメントにアクセスして編集す ることを許可できるか?

8.
[beta]
ロールを基にしたアクセス制御
● グループ/ロールに割り当てられたユーザー
● アプリケーション/APIレベルでの権限
app.get('/expense/approve',
claimIncludes('role', 'approver'),
(req, res) => { ... });

app.get('/expense/approve',
claimIncludes('permissions', 'approve:expenses'),
(req, res) => { ... });

9.

属性を利用し、細かなアクセス制御 ● マネージャーは自分のチームの経費のみ承認できる

10.

ポリシーエンジンを用いたアクセス制御 ポリシーエンジンを実装(ユーザーが経費の提出者のマネージャーかつ、承認の権限を持つか) アプリケーションからこのエンジンを呼び出し

11.

ハードコードされた認可ロジックの課題 認可がどのように 動いているか不明 セキュリティ モジュール間で ⼀貫していない実装 プラットフォーム 監査ログの 不統合 新機能の追加が 困難 製品

12.

ReBACとは?

13.

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/

14.

https://zanzibar.academy/

15.

基本

16.

エディター‧ビューアー

17.

グループ

18.

フォルダー

19.

他のアクセス制御⽅式との⽐較 粒度 認可 ロジック 認可 データ Role-based access control (RBAC) 粗い 集約 集約 Attribute-based access control (ABAC) 細かい アプリケーション コード アプリケーション データベース Policy-based access control (PBAC) 細かい 集約 アプリケーション データベース Relationship-based access control (ReBAC) 細かい 集約 集約 名前

20.

ReBACを実装した OpenFGA

21.

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/

22.

https://openfga.dev/

23.

OpenFGAが提供するもの ● ReBACを適⽤した きめ細やかな認可(Fine-Grained Authorization - FGA)が 可能な認可エンジン(サーバー) ● 開発者向けツール ○ アプリケーション向けのSDK ■ Node.js/Javascript、GoLang、.NET、Python ● CLI ● Visual Studio Code Extension

24.

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

25.

CLIとVS Codeエクステンション CLI: 設定の⼊出⼒などをサポート VSCode Extension: シンタックスハイライト、テーマ、設定ファイルの変換、設定ファイルの検証 OpenFGA CLI - https://github.com/openfga/cli VSCode Extension - https://marketplace.visualstudio.com/items?itemName=openfga.openfga-vscode

26.

Playground - モデルの定義やテスト

27.

認可チェックまでの流れ ● 次の2つを⽤いて関係性を記述 ○ Authorization Model - 1つ以上のType Definitionの組み合わせ ■ 例: ユーザーとドキュメントが定義されている ● ドキュメントは次の関係性を持つ ○ ○ ● 閲覧者 [ユーザー]、編集者 [ユーザー]、オーナー[ユーザー] Relationship Tuple - 関係性を表す構⽂、動的に変わりうる ■ 例:ユーザーのdaizenはドキュメントのスライドに対して 編集者という関係を有する OpenFGAサーバーに対して関係性の確認をリクエストする ○ Q: ユーザー:daizenはドキュメント:スライドに対して閲覧者という関係が あるか?

28.

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

29.
[beta]
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/

}

30.

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

31.

Check ユーザー:daizenはドキュメント:スライドに対して閲覧者という関係があるか?

32.
[beta]
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}`);

33.
[beta]
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
},
// … 省略
]
}
);

34.
[beta]
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
});

35.
[beta]
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}`);

36.

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]

37.

ReBACの利⽤が適しているかどうか? ● ● 考慮すべきと感じた点 ○ 権限のモデルを把握できているか(ドキュメント、フォルダ...あと必要なものは?) ○ オブジェクトやユーザーに対して権限設定、共有設定の追加、更新、削除の頻度は? 実運用に適しているか? ○ チェックは「常に」⾏われる ■ レスポンスタイムやスケーラビリティ ■ エンドポイントのセキュリティ

38.

まとめ‧リソース

39.

まとめ‧リソース ● 「関係性」を⽤いることでより細かなアクセス制御が可能 ○ 利⽤シナリオの検討が必要 ○ Authorization Modelの設計がとても重要に感じる ● OpenFGA - https://openfga.dev/ ● Okta FGA (Authorization as a Service) - https://fga.dev/

40.

認証‧認可機能を実装するなら Customer Identity Cloud(Powered by Auth0) https://a0.to/jp-cic-dev

41.

Thank you! @Neri78