オブジェクトのタグ付け¶
このトピックでは、Snowflakeでタグを使用する方法の概念と手順について説明します。
タグでマスキングポリシーを使用する方法の詳細については、 タグベースのマスキングポリシー をご参照ください。
このトピックの内容:
タグとは¶
タグを使用すると、データスチュワードは、集中型または分散型のデータガバナンス管理アプローチを通じて、コンプライアンス、検出、保護、およびリソースの使用状況のユースケースに関する機密データをモニターできるようになります。
タグは、別のSnowflakeオブジェクトに割り当てることができるスキーマレベルのオブジェクトです。タグをSnowflakeオブジェクトに割り当てると、タグに任意の文字列値を割り当てることができます。Snowflakeは、タグとその文字列値をキーと値のペアとして保存します。タグはスキーマに対して一意である必要があり、タグ値は常に文字列です。
CREATE TAG ステートメントを使用してタグを作成し、タグをオブジェクトに割り当てるときにタグ文字列値を指定します。タグがすでに存在することを前提として、 CREATE <オブジェクト> ステートメントを使用し、オブジェクトの作成中にタグをオブジェクトに割り当てることができます。または、 ALTER <オブジェクト> ステートメントを使用して既存のオブジェクトにタグを割り当てることもできます。
単一のタグを同時に異なるオブジェクトタイプに割り当てることができます(例: ウェアハウスとテーブルを同時に)。割り当て時に、タグ文字列値は、複製することも、一意のままにすることもできます。たとえば、複数のテーブルにcost_centerタグを割り当てることができ、タグの文字列値は常にsalesにすることができます。または、文字列値が異なる場合もあります(例: engineering、marketing、finance)。タグを定義し、Snowflakeオブジェクトにタグを割り当てた後に、タグをクエリしてオブジェクトの使用状況をモニターして、モニター、監査、レポートなどのデータガバナンス操作を容易にすることができます。
タグはテーブル、ビュー、および列に割り当てることができるため、タグを設定してからタグをクエリすると、機密情報を含んでいる多数のデータベースオブジェクトおよび列を検出できます。発見時に、データスチュワードは、 行アクセスポリシー を使用した選択的フィルタリング、または マスキングポリシー を使用した、データのトークン化、完全なマスク化、部分的なマスク化、またはマスク解除の判断により、データの提供に関する最善の方法を決定できます。
ウェアハウスにタグを割り当てると、正確なリソースの使用状況のモニターが可能になります。リソースのタグをクエリすると、コストセンターまたは他の組織単位ごとにリソースを簡単にグループ化できます。さらに、タグを使用すると、プロジェクトのような比較的短期間のビジネスアクティビティの分析が容易になり、どのようなリソースが、いつ、どのように使用されたかについて、より詳細な洞察を得ることができます。
オブジェクトおよび列のタグクォータ¶
各タグの文字列値は最大256文字で、タグに 許可される値 を指定するオプションがあります。
次の説明は、テーブルやビューではないすべてのオブジェクトに適用されます。
Snowflakeでは、単一のオブジェクトに最大50個の 一意な タグを設定できます。CREATE <オブジェクト> または ALTER <オブジェクト> ステートメントでは、単一のステートメントで指定できるタグの最大数は100です。
一意のタグの最大数は、テーブルとビューの列を含め、テーブルとビューでわずかに異なります。
テーブル、ビュー、および列¶
テーブルまたはビューとその列のために、単一の CREATE <オブジェクト> または ALTER <オブジェクト> ステートメントで指定できる一意なタグの最大数は100です。この合計値には次の制限があります。
単一のテーブルまたはビューオブジェクト: 一意なタグ50個。
単一のテーブルまたはビューで結合されたすべての列: 一意なタグ50個。
たとえば、テーブル内の単一の列で10個の一意なタグが列に設定されている場合、Snowflakeは次を許可します。
同じ列、テーブル内の他の列、またはテーブル内の列の組み合わせに40個の追加の一意なタグを設定する。
テーブル自体に50個の追加の一意なタグを設定する。
テーブル自体とその列に対する一意なタグの制限値50に達すると、テーブルまたはその列に追加のタグを設定できなくなります。この時点で、テーブルまたはその列に追加のタグを設定する必要がある場合、考慮すべき次のステップは、オブジェクトのタグクォータを管理する方法です。
タグクォータを管理する¶
一意なタグの最大数50には、 DROP TAG ステートメントを使用してタグがドロップされてから24時間の期限にドロップされたタグが含まれます。この期限の理由は、タグを削除したユーザーが必要に応じて UNDROP TAG ステートメントを実行できるようにするためです。UNDROP TAG 操作が24時間の間隔内に実行されると、Snowflakeはドロップ操作の前に最新だったタグ割り当て(つまり、参照)を復元します。
24時間の期限が切れると、Snowflakeはドロップされたタグに関連するすべての参照をパージします。この時点で、ドロップされたタグを一度参照したオブジェクトまたは列に、新しいタグを割り当てることができます。
次の手順を使用して、オブジェクトのタグクォータを管理します。
TAG_REFERENCES ビュー(Account Usage)をクエリして、タグの割り当てを決定します。
オブジェクトまたは列からタグの設定を解除します。例:
オブジェクトの場合は、対応する
ALTER <オブジェクト> ... UNSET TAG
コマンドを使用します。テーブルまたはビュー列の場合は、対応する
ALTER { TABLE | VIEW } ... { ALTER | MODIFY } COLUMN ... UNSET TAG
コマンドを使用します。DROP TAG ステートメントを使用してタグをドロップします。
タグ値を指定する¶
ALLOWED_VALUES
タグプロパティを使用すると、タグが オブジェクト に設定されている場合に、タグに割り当てることができる選択可能な文字列値を指定できます。1つのタグで可能な文字列値の最大数は300です。
これらの値は、タグを作成または CREATE TAG ステートメントで置き換えるとき、または既存のタグキーを ALTER TAG ステートメントで変更するときに指定できます。ALTER TAG ステートメントは、タグの許可された値の追加 および タグに対する既存の値のドロップをサポートしています。
タグに許可される値のリストを決定するには、 GET_DDL 関数または SYSTEM$GET_TAG_ALLOWED_VALUES 関数を呼び出します。
例:
許可された2つの文字列値として
'finance'
と'engineering'
を使用してcost_center
という名前のタグを作成します。create tag cost_center allowed_values 'finance', 'engineering';次の許可された値を確認します。
select get_ddl('tag', 'cost_center') +------------------------------------------------------------------------------+ | GET_DDL('tag', 'cost_center') | |------------------------------------------------------------------------------| | create or replace tag cost_center allowed_values = 'finance', 'engineering'; | +------------------------------------------------------------------------------+
cost_center
という名前のタグを変更して、許可された文字列値として'marketing'
を追加します。alter tag cost_center add allowed_values 'marketing';
cost_center
という名前のタグを変更して、許可された文字列値として'engineering'
をドロップします。alter tag cost_center drop allowed_values 'engineering';
特定のタグで許可された文字列値のリストを取得するには、 GET_DDL 関数または SYSTEM$GET_TAG_ALLOWED_VALUES 関数を呼び出します。たとえば、タグ cost_center
が governance
という名前のデータベースと tags
という名前のスキーマに保存されていると仮定します。
select system$get_tag_allowed_values('governance.tags.cost_center'); +--------------------------------------------------------------+ | SYSTEM$GET_TAG_ALLOWED_VALUES('GOVERNANCE.TAGS.COST_CENTER') | |--------------------------------------------------------------| | ["finance","marketing"] | +--------------------------------------------------------------+
タグ系統¶
タグは、Snowflakeのセキュリティ保護可能なオブジェクトの階層に基づいて継承されます。Snowflakeは、Snowflake環境の セキュリティ保護可能なオブジェクト の階層にできるだけ近いタグキーを定義することをお勧めします。
タグの継承とは、タグがテーブルに適用される場合、そのタグはそのテーブルの列にも適用されることを意味します。この動作は、タグ系統と呼ばれます。
特定のオブジェクトで継承されたタグを上書きできます。たとえば、テーブルの列が、文字列値がsalesであるcost_centerという名前のタグを継承する場合、タグは、北米の販売コストセンターを指定するsales_naなど、より具体的なタグ文字列値に更新できます。さらに、新しいタグをテーブル列に適用できます。 ALTER TABLE ... ALTER COLUMN ステートメントを使用して、列のタグ文字列値を更新し、列に1つ以上の追加タグを設定します。
タグキーを定義し、Snowflakeオブジェクトにタグを割り当てた後、指定されたテーブル関数を使用してタグ、タグ参照、およびタグ系統をモニターするか、 SQL によるタグのモニター (このトピック内)に示すようにビューをクエリします。
注釈
タグの系統には、ネストされたオブジェクトへの 伝達 が含まれて いません。例:
table_1
»view_1
»materialized_view_1
ネストされたオブジェクトが基になるテーブルまたはビューに相対してすでに存在する場合は、基になるオブジェクトにタグが設定されても、ネストされたオブジェクトにタグが自動的に設定されることはありません。この例では、 table_1
にタグを設定しても、 view_1
と materialized_view_1
に同じタグが設定されることはありません。この動作は列にも当てはまります。
基になるオブジェクトまたは列のタグをネストされたオブジェクトに引き継ぐ必要がある場合は、ネストされたオブジェクトで CREATE OR REPLACE ステートメントを実行し、 合わせて SQL ステートメントが、ネストされたオブジェクトまたは列でタグを指定することを確認します。
利点¶
- 使いやすさ:
タグを一度定義して、必要な数の異なるオブジェクトに適用します。
- タグ系統:
タグは継承されるため、セキュリティ保護可能なオブジェクトの階層の上位にあるオブジェクトにタグを適用すると、すべての子オブジェクトにタグが適用されます。たとえば、タグがテーブルに設定されている場合、そのタグはそのテーブルのすべての列に継承されます。
- 複製での一貫した割り当て:
Snowflakeは、プライマリデータベース内のタグとその割り当てをセカンダリデータベースに複製します。
詳細については、 複製 (このトピック内)をご参照ください。
- 機密データの追跡とリソースの使用:
タグは機密データ(例: PII、シークレット)の識別を簡素化し、Snowflakeリソースの使用状況を可視化します。アナリストは、同じシステム内のデータとメタデータを使用して、タグ定義(例:
cost_center
、department
)に基づいて、どのリソースが最も多くのSnowflakeクレジットを消費しているかをすばやく判断できます。- 集中型または分散型の管理:
タグは、さまざまな管理アプローチをサポートして、内部および外部の規制要件への準拠を促進します。
集中型アプローチでは、
tag_admin
カスタムロールがタグを作成して、Snowflakeオブジェクトに適用します。分散型アプローチでは、個々のチームがSnowflakeオブジェクトにタグを適用し、
tag_admin
カスタムロールがタグを作成して、一貫したタグの命名を確実にします。
考慮事項¶
- 将来の付与:
タグに対する権限の 将来の付与 はサポートされていません。
回避策として、カスタムロールに APPLYTAG 権限を付与して、そのロールが別のオブジェクトにタグを適用できるようにします。
- Snowflake Native App:
バージョン管理されたスキーマにタグが存在する場合は、セットアップスクリプトを作成する際に注意してください。詳細については、 バージョンスキーマの考慮事項 をご参照ください。