Open27

Snowflake

ぺい(pei0804)ぺい(pei0804)

Redshift vs Snoflake
https://levelup.gitconnected.com/snowflake-vs-redshift-ra3-the-need-for-more-than-just-speed-52e954242715
https://www.bmc.com/blogs/aws-redshift-vs-snowflake/
https://www.eweek.com/big-data-and-analytics/snowflake-vs-aws-redshift/

Snowflakeのが簡単でメンテナンスフリーという印象。Redshiftだと多少メンテ頑張る必要がある。特にスケーリング周りなど。あとはクエリがアドホックに比較的重めなやつが適当に投げられると全体が重くなるとか。

あとはJSON系の扱いやすさはSnowflake
https://sonra.io/snowflake/snowflake-vs-redshift-support-for-handling-json/

ぺい(pei0804)ぺい(pei0804)

Our Top 7 Snowflake RBAC Best Practices

https://select.dev/posts/snowflake-rbac-best-practices

ヒント1. 最小特権の原則から始める

わかる。

ヒント2. アクセス、機能、サービスの役割

Access Roles: データベースへのアクセスを制御するために使用されます;
Functional Roles: 社内のSnowflakeユーザに付与され、必要なアクセスロールを付与することでアクセスレベルが制御されます(最小特権の原則に従います);
Service Roles: Functional Rolesと全く同じように機能しますが、唯一の違いはサービス向けであり、エンド(人間)ユーザー向けではないということです。

DRYな役割階層を作る
企業で必要とされる機能的役割とサービス的役割を定義する。

DATA_ANALYSTとかそういう粒度でまとめる。

アクセス ロールを作成する。
機能ロールとサービスロールを作成する(そしてそれらにアクセスロールを付与する)。
ユーザーには機能ロールを、サービスアカウントにはサービスロールを付与する。

わかる

⛔ アクセス ロールをエンド ユーザー/サービス アカウントに直接付与しない。

わかる。

Accessロールの作成時にFutureのGrantを活用する

大事

Grant Functional Roles to SYSADMIN

大事

Tip 7. You probably don't need ACCOUNTADMIN for that…
Or in other words, use appropriate roles for all administrative operations you perform. Remember the Principle of Least Privilege!

The ACCOUNTADMIN role by default has way more privileges than the ones needed for your daily operations/chores, so you should avoid using it unless there is a good reason. Here is what you can use instead for common operations:

ユーザやロールを作成する必要がある場合は、USERADMIN を使用してください!
グラントを管理する (例えば、ユーザーにロールを付与する) 必要がある場合は、SECURITYADMINを使用してください!
データベース、スキーマ、仮想ウェアハウスなどのオブジェクトを作成する必要がある場合は、SYSADMINを使用してください!
テーブルやビューなどのデータベースやデータベースオブジェクトを作成する必要がある場合は、SYSADMINを使用できます!
与えられたテーブル上でアドホックなデータ操作を行いたい場合(SELECTやINSERTのように)、適切なFunctionalロールを使用してください!
最後に、サードパーティのサービスをSnowflakeに接続する場合、ACCOUNTADMIN は絶対に使用しないでください! 代わりに、適切なサービス・ロールを作成して使用してください :)

ぺい(pei0804)ぺい(pei0804)

Snowflake Roles 101: Comprehensive Guide to Access Control

https://select.dev/posts/snowflake-roles

Snowflake は、Role-Based Access Control (RBAC) アプローチに従って、ユーザーや他のシステムがアクセスできること、できることを管理します。 RBAC では、特定の role を持つことは、特定の権限を付与されることを意味します。

  • User - 人(またはサービス)が Snowflake に接続するためのエンティティ。
    Object - ユーザーが適切な権限を持っていればアクセスできるエンティティ(テーブル、ビュー、データベースなど)。
    Privilege - ユーザがオブジェクトに対して実行できる操作。
    Role - ユーザーとプリビレッジの橋渡しをするエンティティ。 特権はロールに付与され、ロールはユーザに付与されます。

PrivilegeはRoleに付与され、RoleはUserに付与され、Userがシステム内のObjectに対して実行できる操作を指定します。

この説明かなり分かりやすいな。

Ownership Privilege
Discretionary Access Control (DAC).
各オブジェクトはそのオブジェクトの作成に使用された Role によって所有されます。 Role がオブジェクトを所有するということは、OWNERSHIP権限を持つことを意味します。

Role
SnowflakeのRoleは鍵だと考えることができます。 あなたは自宅の鍵、車の鍵、オフィスの鍵を持っています。 もし近所に親しい人がいれば、その人があなたの家のスペアキーを持っているかもしれません(緊急時に備えて)。 あなたの家の鍵は、あなたとあなたの隣人の両方にアクセスを許可します。

Role Types

  • account roles
  • database roles
  • instance roles

Role Hierarchy

Default Snowflake Account Roles