データカタログのアクセスコントロールを考える

Transcript

1. データカタログのアクセスコントロールを 考える 2025.6.9 primeNumber Inc.
2. AGENDA 2 1. アクセスコントロールのモデル 2. データカタログへの適用 3. COMETAへの実装の適用
3. 3 中村 愛美 @mnmandahalf 株式会社primeNumber Software Engineer SE, HR Webサービス開発を経て2023.5 primeNumber入社 クラウドデータカタログCOMETAの開発をしています AI機能以外の全般的な開発を担当 好きな機能はリネージ Personally, Ruby DX promoter & Web Security Beginner
4. 4 アクセスコントロールのモデル
5. 5 基礎 - DAC / MAC DAC (Discretionary Access Control) • 所有者主体の「任意アクセス制御」。所有者がアクセス権を設定する。 • OSやファイルシステムで使われる • 例：Linuxのchmod, chown MAC (Mandatory Access Control) • システム主体の「強制アクセス制御」。管理者が一貫したポリシーを定義。 • 政府や軍のシステムで使われる • 例：SELinux, AppArmor
6. 6 アクセスコントロールモデル - RBAC / ABAC / ReBAC RBAC (Role-Based Access Control) • ユーザーがロールに割り当てられ、ロールにリソースへのアクセス権が与えられる • エンタープライズシステムで用いられることが多い ABAC (Attribute-Based Access Control) • ユーザーの所属や、日時、位置情報など、複数の属性の組み合わせにアクセス権が 与えられる • クラウド環境やWebアプリケーションで用いられることが多い ReBAC (Relation-Based Access Control) • 「関係性」に基づいてアクセス権限を決定するアクセス制御モデル • 例：友達だからこの写真を見れる • グラフ構造で関係性を表現する • GoogleのZanzibar, OpenFGA
7. 7 データカタログへの適用
8. 8 アクセスコントロールモデルのデータカタログへの適用 OpenMetadata • RBACとABACの要素を組み合わせたハイブリッドモデルを採用1 • RoleはPolicyの集合 • PolicyはRuleの集合 • RuleはResources, Operations, Effects (Allow/Deny), and conditionsを指定する • RoleはUser, Teamにアサインできる • 他にも、タグベースのアクセス制御やチーム階層化、チームへのポリシー割り当て などができる 1: https://docs.open-metadata.org/latest/how-to-guides/admin-guide/roles-policies
9. 9 アクセスコントロールモデルのデータカタログへの適用 Alation • RBACとABACの要素を組み合わせたハイブリッドモデルを採用1 • Role: Viewer, Editor, Data Steward, Data Source Admin, Admin • 特定のデータソースやオブジェクトに対するより詳細なアクセス制御を可能にする 機能も提供 • ユーザーグループ管理やデータソースのPublic/Privateモードもある 1: https://www.alation.com/docs/en/latest/welcome/CatalogBasics/AccessRolesPermissions.html
10. 10 アクセスコントロールモデルのデータカタログへの適用 Atlan • RBACとABACの要素を組み合わせたハイブリッドモデルを採用1 • Role: Admin, Member, Guest • 特定アセット（データストア、テーブル、カラムなど）やタグ、ユーザー属性と いった属性に基づいてアクセス制限できる • Personasという独自の概念があり、特定のユーザーグループにアクセスポリシーの 集合体を紐づけることができる 1: https://ask.atlan.com/hc/en-us/categories/6319495855121-Administration
11. 11 アクセスコントロールモデルのデータカタログへの適用 まとめ • 各種データカタログでは、通常それぞれのアクセス制御モデルが持つ強みを組み合 わせ、データアクセス管理における複雑なニーズに対応している • RBAC的な部分: 「データアナリスト」「データエンジニア」「データオーナー」と いった役割を定義して権限を割り当て、基本的な権限のバンドルを行っている • ABAC的な部分: 特定の機密データ等へのアクセスを特定の条件をもとに拒否する、 タグによるアクセス制御、オーナーシップの概念など、より細かな条件の組み合わ せが可能
12. 12 COMETAへの適用
13. 13 アクセスコントロールモデルのCOMETAへの適用 COMETAは現在RBACで各種リソースへのアクセスを制御している • アカウントロール ◦ アカウント特権管理者 ◦ アカウント管理者ロール ◦ アカウントメンバーロール • COMETAユーザーロール ◦ データストア管理者ロール ◦ メタデータ編集者ロール ◦ 実データ閲覧者ロール
14. 14 課題 • メタデータの閲覧を制御するロールがなく、COMETAユーザーであればアカウント に連携されているデータストア配下の全てのアセット、およびアセットに紐づく全 てのメタデータを閲覧可能となっている 要望・要件 • 特定のデータストア、アセットのみ閲覧可能・編集可能にしたい • 自分が連携したデータストアへのアクセスは保ちたい • データストアへのアクセス権限があれば、テーブルにもアクセスしたい • データストア全体にアクセスできるが、一部テーブルのアクセス権限は無くしたい • チームにアクセス権があれば、自分もアクセスできるようにしたい • ユーザーは複数のチームに所属できるようにしたい アクセスコントロールモデルのCOMETAへの適用
15. 15 採用した内容 • チーム管理機能の追加 • データストアオーナーの概念の追加 ◦ DACをイメージ ◦ 各部署が管理の主体になるケースを想定 ◦ 特権管理者（情シスをイメージ）も権限を管理することができる ◦ 連携単位を考えると、データセットやテーブルといった子要素のオーナーは 権限管理の主体としては不要 アクセスコントロールモデルのCOMETAへの適用
16. 16 • 1. 自分がデータストアのオーナーまたは特権管理者か？ • 2. 所属チーム①がテーブルにアクセス権があるか？ • 3. 所属チーム①がスキーマにアクセス権があるか？ • 4. 所属チーム①がデータベースにアクセス権があるか？ • 5. 所属チーム①がデータストアにアクセス権があるか？ • 6〜 所属チーム②について、2〜4の繰り返し アクセスコントロールモデルのCOMETAへの適用
17. 17 アクセスコントロールモデルのCOMETAへの適用 https://www.osohq.com/academy/relationship-based-access-control-rebac#resources 図はOSOのサイトから Authorization with Parent-Child Resourcesパター ンを抜粋 リソースの階層と（図にはな いが）所属チームの数だけ ループが発生
18. 18 Q. チームは擬似的なロール？属性？ ロールにも属性にもなりうる RBACのロールとしてチームを使用する例 • 管理者チーム・・・全てのアクションが可能 • 編集者チーム・・・編集が可能 • 閲覧者チーム・・・閲覧が可能 ABACの属性としてチームを使用する例 → 今回はおそらくこちら • Corporate IT team: 給与情報に関するテーブルが閲覧できる • Account team: 決算情報に関するテーブルが閲覧できる
19. 19 実装への統合
20. 20 実装への統合 • 基本エンティティ ◦ users / teams / team_users ◦ catalogs / catalog_databases / catalog_schemas / catalog_tables • アクセス制御構成（階層ごと） ◦ team_catalog_permissions ◦ team_database_permissions ◦ team_schema_permissions ◦ team_table_permissions
21. 21 実装への統合 テーブルへのアクセス方法は主に以下のように分類できる • 詳細表示 ◦ ユーザーにそのリソースへのアクセス許可があるか確認するだけなので、 最も簡単 • リネージ、ERD ◦ 少数（< 20程度）のテーブルやダッシュボードに対してチェックするだけなの で、詳細表示と大きく変わらない • リスト、検索結果表示 ◦ 権限のチェックとページングの両立が必要 ◦ 検索クエリでチェックする場合、インデクシングの工夫が必要
22. 22 実装への統合（リスト） -- ユーザーがアクセス可能なテーブル一覧（deny優先） SELECT DISTINCT ct.* FROM catalog_tables ct JOIN catalog_schemas cs ON ct.schema_id = cs.id JOIN catalog_databases cd ON cs.database_id = cd.id JOIN catalogs c ON cd.catalog_id = c.id JOIN users u ON u.id = :user_id -- ユーザー所属チーム JOIN team_users tu ON tu.user_id = u.id JOIN teams t ON tu.team_id = t.id -- 左結合で各階層のアクセス権取得（allow/deny 両方見る） LEFT JOIN team_table_permissions ttp_allow ON ttp_allow.team_id = t.id AND ttp_allow.table_id = ct.id AND ttp_allow.can_view = TRUE LEFT JOIN team_table_permissions ttp_deny ON ttp_deny.team_id = t.id AND ttp_deny.table_id = ct.id AND ttp_deny.can_view = FALSE LEFT JOIN team_schema_permissions tsp_allow ON tsp_allow.team_id = t.id AND tsp_allow.schema_id = cs.id AND tsp_allow.can_view = TRUE LEFT JOIN team_schema_permissions tsp_deny ON tsp_deny.team_id = t.id AND tsp_deny.schema_id = cs.id AND tsp_deny.can_view = FALSE LEFT JOIN team_database_permissions tdp_allow ON tdp_allow.team_id = t.id AND tdp_allow.database_id = cd.id AND tdp_allow.can_view = TRUE LEFT JOIN team_database_permissions tdp_deny ON tdp_deny.team_id = t.id AND tdp_deny.database_id = cd.id AND tdp_deny.can_view = FALSE LEFT JOIN team_catalog_permissions tcp_allow ON tcp_allow.team_id = t.id AND tcp_allow.catalog_id = c.id AND tcp_allow.can_view = TRUE LEFT JOIN team_catalog_permissions tcp_deny ON tcp_deny.team_id = t.id AND tcp_deny.catalog_id = c.id AND tcp_deny.can_view = FALSE WHERE -- 明示的な拒否がない（deny優先） ttp_deny.team_id IS NULL AND tsp_deny.team_id IS NULL AND tdp_deny.team_id IS NULL AND tcp_deny.team_id IS NULL AND ( -- スーパーユーザー u.account_role = 'super_admin' -- オーナー OR c.owner_id = u.id -- チーム経由で allow が1つでもあれば OK OR ttp_allow.team_id IS NOT NULL OR tsp_allow.team_id IS NOT NULL OR tdp_allow.team_id IS NOT NULL OR tcp_allow.team_id IS NOT NULL ) ;
23. 23 実装への統合（検索） クエリでの絞り込み • pros ◦ ページング実装の簡潔さ ◦ 検索結果を返すまでのパフォーマンス • cons ◦ 権限変更から検索への反映ロジックの複雑性、タイムラグ 検索結果フィルタ • pros ◦ 権限変更が検索結果に即反映できる • cons ◦ ページング実装の複雑さ ◦ 検索結果を返すまでのパフォーマンスが悪くなる
24. 24 まとめ
25. 25 まとめ • データカタログプロダクトの権限管理は、概ね以下のようになっている ◦ RBAC for basic roles ◦ ABAC for more further details • 実装に統合する際は、リスト表示や検索に課題がある 皆さんの実践している認可システムのモデルと実装についても教えてください！
26. Thank you!