Role 層 Warehouse Account Role Service_R Database Warehouse Account Role Service_RW Access Role 層 System User 2 Human User A Human User B System User 1 Database Role table-create Database Role table-select tables views Database Role view-create Database Role view-select Functional Role 層 Warehouse Account Role Service_RW Warehouse Account Role Service_R Database Role ReadWrite Database Role Read
- RBAC オブジェクトの権限はロールに付与され、ロールはユーザーに付与される、という形で権限管理する 9 https://select.dev/posts/snowflake-roles より GRANT USAGE ON DATABASE DBA; TO ROLE RA; GRANT ROLE RA TO USER UA;
導入直後 各エンジニアがロール・ウェアハウスを管理。初期はルールもほぼなく、様々な問題があった • Snowflake の権限についてよく知らないと管理できない • ロール階層について理解していないと管理できない • ウェアハウスの切り分けが雑 14 System User 2 Human User A Human User B System User 1 Account Role Account Role Account Role Tables Views Warehouse Account Role Account Role Account Role Account Role Warehouse Warehouse
を用意（Access Role 層）。 Access Role を他のロールへ付与する形で DBオブジェクトの権限を付与する。 Database Access Role 層 3. ナウキャストの権限管理・コスト管理の変遷 フェーズ② - Access Role 層の作成 15 System User 2 Human User A Human User B System User 1 Account Role Database Role table-create Database Role table-select Tables Views Warehouse Database Role view-create Database Role view-select Account Role Account Role Warehouse
Database Access Role 層 3. ナウキャストの権限管理・コスト管理の変遷 フェーズ② - Access Role 層の作成 16 System User 2 Human User A Human User B System User 1 Account Role Database Role table-create Database Role table-select Tables Views Warehouse Database Role view-create Database Role view-select Account Role Account Role Warehouse
を付与するかどうかで権限管理する。 また Account Role 同士で階層をなくすことでシンプルに。 Account Role と Warehouse をセットにし、 権限管理とコスト管理を同時にしやすくした。 Database Warehouse Account Role ReadWrite Access Role 層 3. ナウキャストの権限管理・コスト管理の変遷 フェーズ③ - 階層を無くし、 Account Role と Warehouse をセットに 17 System User 2 Human User A Human User B System User 1 Warehouse Account Role Read Database Role table-create Database Role table-select Tables Views Database Role view-create Database Role view-select
Account Role ReadWrite Access Role 層 3. ナウキャストの権限管理・コスト管理の変遷 フェーズ③ - 階層を無くし、 Account Role と Warehouse をセットに 18 System User 2 Human User A Human User B System User 1 Warehouse Account Role Read Database Role table-create Database Role table-select Tables Views Database Role view-create Database Role view-select
を、人間は Functional Role を使うことで、ロールもウェアハウスも 管理しやすく！ Service Role 層 Warehouse Account Role Service_R Database Warehouse Account Role Service_RW Access Role 層 3. ナウキャストの権限管理・コスト管理の変遷 フェーズ④ - Service / Functional Role 層の作成 19 System User 2 Human User A Human User B System User 1 Database Role table-create Database Role table-select Tables Views Database Role view-create Database Role view-select Functional Role 層 Warehouse Account Role Service_RW Warehouse Account Role Service_R
Role 層で一つ階層を追加。 Service Role 層 Warehouse Account Role Service_R Database Warehouse Account Role Service_RW Access Role 層 3. ナウキャストの権限管理・コスト管理の変遷 フェーズ⑤ - Access Role 層に必要に応じて一つだけ階層を作る 20 System User 2 Human User A Human User B System User 1 Database Role table-create Database Role table-select Tables Views Database Role view-create Database Role view-select Functional Role 層 Warehouse Account Role Service_RW Warehouse Account Role Service_R Database Role ReadWrite Database Role Read
ではロールとウェアハウスの使い方をどうするか？という話 • 以下の３つの層に分けて考えると管理しやすい ◦ Access Role 層 ▪ Database / Schema 内のオブジェクトの権限を表現するためのロールの層 ▪ Database Role で実装する ◦ Functional Role 層 ▪ 人間が使うロールとウェアハウスの層で、役割ごとに分離する ▪ Account Role で実装する ▪ Functional Role 同士で階層は作らない ▪ Access Role を付与するかどうかで DB / Schema 内のオブジェクトの権限管理をする ◦ Service Role 層 ▪ Functional Role 層と基本同じだが、利用者が人間ではなくシステム 21
権限管理もSchema単位で考えていくとやりやすい ◦ FUTURE TABLES / ALL TABLES といった grant がある ▪ GRANT SELECT ON FUTURE TABLES IN SCHEMA s1 TO DATABASE ROLE r1; ▪ GRANT SELECT ON ALL TABLES IN SCHEMA s1 TO DATABASE ROLE r1; ◦ Schema 単位でオブジェクトをまとめて考えることで、 FUTURE / ALL の Grant が利用でき 必要となる Grant が一気に減る（増えない）ため、管理しやすくなる ◦ このように Grant も奥が深いので、 Access Role 層として適切な粒度のロールを 用意しておくと権限管理のハードルが下がる 27 例：テーブル Schema 単位 オブジェクト単位 権限管理の単位 <db>.<schema> 内の全テーブル <db>.<schema>.<table> 必要な Grant 以下の2つを privilege ごとに設定すれば、追加は不要 - FUTURE/ALL TABLES IN SCHEMA テーブル・privilege ごとに設定 テーブルの増減に伴いgrant系の設定も増減が必要
構成のアンチパターン • Access Role を Account Role で作る ◦ Access Role は単に権限をまとめて使いやすくしたものなので Account Role でなくて良い ◦ Account Role で作成すると Role が多すぎて Role 選択画面が大変なことになる • Access Role の作り方が雑 ◦ 荒すぎると権限管理がうまくできないし、細かすぎても使いにくい ◦ 最初に程よい粒度で作るのが大事 • Functional / Service Role の中で階層を作る ◦ 複雑な階層になり、管理しきれなくなりがち ◦ 結果として強めの権限のロールが多用されがち • Ownership の取り扱いを考えない ◦ Owner 権限を持つ Access Role を用意し、必要に応じて複数の Role に Table の Owner な どを配れるようにしておくのが大事 ◦ そうでないと Functional Role 側の階層が必要になり複雑になる • 命名が雑 29
モジュール② : Role / Warehouse モジュール ◦ 管理対象 ▪ Functional / Service Role となる Account Role ▪ 指定した Access Role である Database Role の Grant ▪ Warehouse とその Grant • 誰が開発するか？ ◦ モジュール自体の開発は Platform チーム ▪ Access Role をモジュール①で実装するなど ◦ モジュールを利用し実際のオブジェクトを作るのは各チームのエンジニア ▪ モジュール①・②を利用しプロダクトの Schema と 関連する Functional / Service Role を用意する ▪ どのような Access Role があるのかを理解していれば簡単に権限管理ができる 32
kevinrobot34
brad_frost
rasmusluckow
eileencodes
garrettdimon
chrislema
mongodb
frogandcode
ufuk
lemiorhan
lara
moore
holman
