分類の紹介¶
この機能には、Enterprise Edition以上が必要です。アップグレードについては、 Snowflakeサポート にお問い合わせください。
このトピックでは、分類のしくみに関する情報を提供します。
このトピックの内容:
概要¶
分類は、個人データのセルとメタデータを分析することにより、Snowflakeで定義されたタグ（つまり、システムタグ）を列に関連付ける多段階プロセスです。データエンジニアはこのデータを追跡できるようになりました。
追跡情報と関連する監査プロセスに基づいて、データエンジニアは個人データや機密データを含む列をマスキングポリシーで保護したり、この列を含むテーブルを行アクセスポリシーで保護したりできます。
分類およびデータ保護ステップの全体的な結果は、データプライバシー規制への準拠を促進することです。
プロセス¶
このセクションでは、分類の3段階のプロセスがどのように機能するかについて説明します。このプロセスは、テーブルに新しい行を挿入した後やテーブルに新しい列を追加した後など、必要に応じて何度でも繰り返すことができます。
分類は、分析、レビュー、適用という3段階のプロセスに簡素化されます。これらの各ステップには、異なる操作があります。
- 分析
データエンジニアは、Snowflakeアカウントで EXTRACT_SEMANTIC_CATEGORIES 関数を呼び出します。この関数は、テーブル内の列を分析し、使用可能なカテゴリおよび関連する確率を出力します。確率値は、使用可能なカテゴリによって定義された個人データが列に含まれる可能性を示します。詳細については、 分類出力の解釈 （このトピック内）をご参照ください。
注釈
複数のオブジェクトに対して JOIN 操作を必要とするビューなどの複雑なビュー定義は、分析プロセスを遅くする可能性があります。複雑なビューを分類する前に、稼働中のウェアハウスを検討してください。詳細については、 コンピューティングコスト （このトピック内）をご参照ください。
- レビュー
レビューのステップでは、データエンジニアがカテゴリの結果をレビューして、分析ステップ操作の結果が意味を成すことを確認します。修正が必要ない場合、データエンジニアは適用ステップに進むことができます。
修正が必要な場合、データエンジニアは適用ステップに進む前に分析ステップの出力を修正できます。
詳細については、 分類出力の解釈 （このトピック内）をご参照ください。
- 適用
適用ステップには、システムタグの割り当てという1つの操作があります。
データエンジニアは、列にシステムタグを手動で設定するか、 ASSOCIATE_SEMANTIC_CATEGORY_TAGS ストアドプロシージャを呼び出すことができます。
システムタグを割り当てた後、データエンジニアは システムタグを追跡 し、マスキングポリシーまたは行アクセスポリシーを使用して個人データや機密データを保護できます。
このプロセスの詳細な例については、 データ分類の使用 をご参照ください。
システムタグおよびカテゴリ¶
システムタグは、Snowflakeが共有 SNOWFLAKE データベース で作成、維持、および利用できるようにするタグです。2つの分類システムタグがあり、どちらも SNOWFLAKE.CORE スキーマに存在します。
SNOWFLAKE.CORE.SEMANTIC_CATEGORYSNOWFLAKE.CORE.PRIVACY_CATEGORY
データエンジニアは、個人データまたは機密データを含む列にこれらのタグを割り当てます。
- 文字列値
Snowflakeは、列でのシステムタグの割り当てをキーと値のペアとして保存します。値は文字列です。Snowflakeはこれらの各システムタグを維持するため、Snowflakeは各分類システムタグに許可される文字列値を定義します。
Snowflakeアカウントで SYSTEM$GET_TAG_ALLOWED_VALUES 関数を呼び出して、サポートされている分類システムタグ文字列値のリストを表示します。例:
select system$get_tag_allowed_values('snowflake.core.semantic_category'); select system$get_tag_allowed_values('snowflake.core.privacy_category');
タグ名 SEMANTIC_CATEGORY および PRIVACY_CATEGORY は、列サンプリングプロセス中にSnowflakeが列データに割り当てる、分類カテゴリに対応します（つまり、タグ名とカテゴリ名は同じ単語を使用します）。
- セマンティックカテゴリ
セマンティックカテゴリは、個人の属性を識別します。
分類がサポートする個人属性の非網羅的なリストには、名前、年齢、性別が含まれます。これら3つの属性は、
SEMANTIC_CATEGORYタグを列に割り当てるときに使用可能な文字列値です。- プライバシーカテゴリ
分析により、列データがセマンティックカテゴリに対応すると判断された場合、Snowflakeはさらに列をプライバシーカテゴリに分類します。プライバシーカテゴリには、識別子、準識別子、機密の3つの値があります。これら3つの値は、
PRIVACY_CATEGORY分類システムタグを列に割り当てるときに指定できる文字列値です。識別子: これらの属性は、個人を一意に識別します。属性の例には、名前、社会保障番号、電話番号などがあります。
識別子属性は 直接識別子 と同義です。
準識別子: これらの属性は、2つ以上の属性が組み合わされた場合に、個人を一意に識別することができます。属性の例には、年齢と性別が含まれます。
準識別子は 間接識別子 と同義です。
機密: これらの属性は、個人を識別するのに十分とは見なされませんが、個人がプライバシー上の理由で開示を望まない情報です。
現在、Snowflakeが機密と評価する唯一の属性は給与です。
次のテーブルは、各分類カテゴリとシステムタグの関係、各分類システムタグに使用できる文字列値、および各システムタグのシステムタグ文字列値をまとめたものです。
|
|
|---|---|
|
|
|
|
|
|
注釈
3つのプライバシーカテゴリすべてからの複数のセマンティックタグ文字列値は、「機密性の高い個人データ」、「データの特別なカテゴリ」、または法規制に基づく同様の用語と見なされ、追加の保護または制御が必要になる場合があります。
現在、分類では、列データに機密性と識別性の両方のタグが付けられていません。つまり、特定の列にシステムタグを設定する場合は、 SEMANTIC_CATEGORY または PRIVACY_CATEGORY タグのいずれかを選択する必要があります。
分類出力の解釈¶
EXTRACT_SEMANTIC_CATEGORIES 関数は、半構造化形式である JSON 形式の次を含む VARIANT を返します。
0.8を超えるの可能性のあるセマンティックおよびプライバシーカテゴリは、
extra_infoの外側にリストされ（EXTRACT_SEMANTIC_CATEGORIES 関数を参照）、 ASSOCIATE_SEMANTIC_CATEGORY_TAGS ストアドプロシージャによって適用されるものでもあります。分類プロセスが正しいセマンティックカテゴリを導き出した確率。
列にタグを付けることができる代替セマンティックカテゴリのリスト（確率が
0.80しきい値を下回り、プロセスが0.15より大きい確率で他の可能なセマンティックカテゴリを識別する場合）。ただし、これらの値を使用するには、データエンジニアがシステムタグを手動で設定するか、出力を修正する必要があります。
確率値は、列に個人データまたは機密データが含まれているかどうかについて、データエンジニアが十分な情報に基づいて決定するのに役立ちます。確率が高いほど、列に含まれている可能性が高くなります。
以下は、 データ分類の使用 に示されている 単一のテーブルを分類する の例を簡略化した例です。
テーブルを作成します。
CREATE TABLE hr_data ( age INTEGER, email_address VARCHAR, fname VARCHAR, lname VARCHAR );
テーブルにデータをロードしてから、 EXTRACT_SEMANTIC_CATEGORIES 関数を呼び出します。
USE ROLE data_engineer; SELECT EXTRACT_SEMANTIC_CATEGORIES('hr_data');
出力を評価します。例:
デフォルトの出力:
SELECT EXTRACT_SEMANTIC_CATEGORIES('hr_data'); +---------------------------------------------+ | EXTRACT_SEMANTIC_CATEGORIES('HR_DATA') | |---------------------------------------------| | { | | "AGE": { | | "extra_info": { | | "alternates": [], | | "probability": "1.00" | | }, | | "privacy_category": "QUASI_IDENTIFIER", | | "semantic_category": "AGE" | | }, | | "EMAIL_ADDRESS": { | | "extra_info": { | | "alternates": [], | | "probability": "1.00" | | }, | | "privacy_category": "IDENTIFIER", | | "semantic_category": "EMAIL" | | }, | | "FNAME": { | | "extra_info": { | | "alternates": [], | | "probability": "1.00" | | }, | | "privacy_category": "IDENTIFIER", | | "semantic_category": "NAME" | | }, | | "LNAME": { | | "extra_info": { | | "alternates": [], | | "probability": "0.97" | | }, | | "privacy_category": "IDENTIFIER", | | "semantic_category": "NAME" | | } | | } | +---------------------------------------------+
FLATTEN テーブル関数を使用して読みやすくします。
SELECT f.key::varchar as column_name, f.value:"privacy_category"::varchar as privacy_category, f.value:"semantic_category"::varchar as semantic_category, f.value:"extra_info":"probability"::number(10,2) as probability, f.value:"extra_info":"alternates"::variant as alternates FROM TABLE(FLATTEN(EXTRACT_SEMANTIC_CATEGORIES('hr_data')::VARIANT)) AS f; +---------------+------------------+-------------------+-------------+------------+ | COLUMN_NAME | PRIVACY_CATEGORY | SEMANTIC_CATEGORY | PROBABILITY | ALTERNATES | |---------------+------------------+-------------------+-------------+------------| | AGE | QUASI_IDENTIFIER | AGE | 1.00 | [] | | EMAIL_ADDRESS | IDENTIFIER | EMAIL | 1.00 | [] | | FNAME | IDENTIFIER | NAME | 1.00 | [] | | LNAME | IDENTIFIER | NAME | 0.97 | [] | +---------------+------------------+-------------------+-------------+------------+
一部のフィールド（例:
PROBABILITYフィールド）にある値は、データの特性とサンプルサイズによって異なることに注意してください。
サポートされているオブジェクトおよび列のデータ型¶
Snowflakeは、外部テーブル、マテリアライズドビュー、セキュアビューなど、すべての型のテーブルとビューに保存されているデータの分類をサポートしています。
サポートされているすべての データ型 のテーブルとビューの列を分類できます。ただし、次のデータ型は 除きます。
GEOGRAPHY
BINARY
VARIANT
列のデータ型を NUMBER または STRING データ型に キャスト できる場合は、列を VARIANT データ型で分類できることに注意してください。列に JSON、 XML、またはその他の半構造化データが含まれている場合、Snowflakeは列を分類しません。
テーブルにサポートされているデータ型ではない列が含まれている場合、または列にすべての NULL 値が含まれている場合、分類プロセスは列を無視し、出力に含めません。
重要
データが NULL 以外の値を持つ NULL 値を表す場合は、分類結果の精度に影響を与える可能性があります。
コンピューティングコスト¶
分類プロセスには、分類が実行されるときに使用および実行されている、 仮想ウェアハウス によって提供されるコンピューティングリソースが必要です。
テーブル/ビュー内のデータを分類するために必要な時間（したがって、ウェアハウスによって消費されるクレジットの数）は、分類されるデータの量の関数です。
特に、テーブル/ビューに分類をサポートする列が多数ある場合は、処理時間に影響を与える可能性があります。ただし、原則として、処理速度はウェアハウスのサイズに比例します。言い換えると、ウェアハウスのサイズが大きくなるごとに（例: XSからS）、通常、処理時間が半分に短縮されます。
次の一般的なガイドラインに従って、 ウェアハウスのサイズ を選択します。
処理時間の考慮なし: XSウェアハウス。
テーブル内の列が最大100列: Sウェアハウス。
テーブル内の列が101列から300列: Mウェアハウス。
テーブル内の列が301列以上: Lウェアハウス。
利点¶
分類は、データのプライバシーとデータガバナンスの管理者に次の利点を提供します。
- データアクセス
列データを分類した結果は、IDおよびアクセス管理の管理者に、Snowflakeの ロール階層 を評価および維持して、Snowflakeのロールが機密データまたは PII データへの適切なアクセス権を確保するように通知できます。
- データ共有
分類プロセスは、 PII データのストレージの場所を特定して確認するのに役立ちます。その後、データ共有プロバイダーは分類結果を使用して、データを共有するかどうか、またデータ共有コンシューマーが PII データを利用できるようにする方法を決定できます。
- ポリシーの適用
ベーステーブル内の列を参照してビューまたはマテリアライズドビューを作成するなど、 PII データを含む列を使用すると、マスキングポリシーまたは行アクセスポリシーのいずれかを使用してデータを保護するための最適なアプローチを決定するのに役立ちます。
推奨事項¶
分類機能を活用して PII データ追跡機能を最適化するには、次を実行します。
- 検証
最初にAccount Usageビューをクエリします。
ACCESS_HISTORY: 最も頻繁にアクセスされるテーブルおよびビューオブジェクトを判定します。
OBJECT_DEPENDENCIES: 2つ以上のオブジェクト間のメタデータ参照を判定します。
クエリ結果を使用して、分類システムタグのスキーマレベルまたはデータベースレベルの割り当てに優先順位を付けます。
- 列名
テーブルオブジェクトで適切な列名を使用し、テーブル作成者をトレーニングして、内部のテーブル作成ガイドラインに準拠させます。
- データ型
列には適切なデータ型を使用します。たとえば、 AGE 列には NUMBER データ型が必要です。
- VARIANT
列のデータ型が VARIANT の場合は、テーブルを分類する前に列に対して FLATTEN コマンドを使用します。
- 確認
EXTRACT_SEMANTIC_CATEGORIES 関数を呼び出した結果を仮テーブルに保存し、分類システムタグを割り当てる前に結果を再確認します。
システムタグを割り当てた後に、 TAG_REFERENCES および COLUMNS のAccount Usageビューをクエリして、分類されていない列を調べます。
たとえば、 GOVERNANCE_VIEWER データベースロールを
data_engineerカスタムロールに付与し、次のステートメントを実行します。use role accountadmin; grant database role governance_viewer to role data_engineer; use role data_engineer; select table_name, table_catalog from snowflake.account_usage.columns c where not exists( select * from snowflake.account_usage.tag_references t where c.column_id = t.column_id ) and deleted is null order by table_catalog;
クエリ結果を使用して、どのテーブルカタログ（データベースなど）が最も重要であるかを判断し、テーブルの分類を再確認して優先順位を付けます。
- 記録
EXTRACT_SEMANTIC_CATEGORIES 関数を呼び出した結果と分類システムタグを割り当てた結果の履歴記録を作成します。
- ウェアハウス
データを分類するときは、適切なウェアハウスサイズを使用します。詳細については、 コンピューティングコスト （このトピック内）をご参照ください。
分類の管理¶
権限リファレンス¶
次のテーブルは、分類の 分析と確認のステップ に最低限必要な権限をまとめたものです。
権限 |
オブジェクト |
メモ |
|---|---|---|
USAGE |
データベースおよびスキーマ |
この権限は、分類する列を含むテーブルの親データベースとスキーマに必要です。 |
SELECT , UPDATE |
テーブル |
SELECT 権限により、列データを分類したり、 EXTRACT_SEMANTIC_CATEGORIES 関数を呼び出したりするために必要なテーブルをクエリできるようになります。 UPDATE 権限により、 ASSOCIATE_SEMANTIC_CATEGORY_TAGS ストアドプロシージャを呼び出して、分類結果をテーブル内の列に自動で適用できるようになります。 |
分類での 適用ステップ、特に システムタグの設定 に必要な権限は、選択したアプローチによって異なります。現在、次の3つのオプションがあります。
GOVERNANCE_ADMIN データベースロールを使用します。
IMPORTED PRIVILEGES をカスタムロールに付与します。
ACCOUNTADMIN ロールを使用します。
- データベースロール
データベースロールのアプローチでは、 GOVERNANCE_ADMIN データベースロール を使用して、テーブル列に分類システムタグを設定します。さらに、データエンジニアには、所有していないオブジェクトにタグを設定するための APPLY TAG グローバル権限があります。
これを実行するには、
GOVERNANCE_ADMIN データベースロールを任意のカスタムロールに付与します（例:
data_engineer）。use role accountadmin; grant database role snowflake.governance_admin to role data_engineer; grant apply tag on account to role data_engineer;
テーブル列にシステムタグを割り当てます。たとえば、
hr.tables.empl_infoという名前のテーブルの EMAIL 列（つまり、人事データベースの従業員情報のテーブル）です。use role data_engineer; alter table hr.tables.empl_info modify column email set tag snowflake.core.semantic_category = 'email';
データベースロールのアプローチを使用すると、プリンシパルの最小権限の要件を満たすことができます。
- カスタムロール
カスタムロール（つまり、作成するアカウントレベルのロール）のアプローチでは、選択したロールに2つの権限を付与する必要があります。例:
use role accountadmin; grant imported privileges on database snowflake to role data_engineer; grant apply tag on account to role data_engineer;
これら2つの付与ステートメントの結果、共有 SNOWFLAKE データベースへのアクセス権が付与され、アカウント内の任意のテーブル列に分類システムタグが適用されます。
data_engineerロールを持つユーザーは、データベースロールのアプローチで示されているように、テーブルに分類システムタグを設定できます。ただし、このアプローチの2つの付与ステートメントでは、次も許可されます。
共有 SNOWFLAKE データベース内にあるすべてのビューをクエリするためのフルアクセス。
アカウントでタグ付けできる任意のオブジェクトに、アカウント内の任意のタグを設定します。
カスタムロールのアプローチが最小権限の原則の要件を満たさない場合は、データベースロールのアプローチを使用します。
- ACCOUNTADMIN
ACCOUNTADMIN ロールを使用する場合は、追加の付与ステートメントは必要ありませんが、 ACCOUNTADMIN ロールはSnowflakeで最も権限のあるロールです。
実稼働環境で ACCOUNTADMIN ロールの使用を限定する制限がある場合は、データベースロールのアプローチまたはカスタムロールのアプローチのいずれかを使用します。
列データの保護に関しては、マスキングポリシーまたは行アクセスポリシーを割り当てる権限を data_engineer ロールに付与するか、別のロールがポリシーの割り当てを担当することができます。どのアプローチを取るかは、管理者がどのように権限を付与し、ロールを管理するかによって異なります。
代表的な例については、 データ分類の使用 をご参照ください。
追跡分類システムタグ¶
Snowflakeは、分類システムタグの使用状況を追跡する組み込みのビューと関数を提供します。
アカウントでシステムタグを含む列を見つけるには、Account Usage TAG_REFERENCES ビューをクエリします。
SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.TAG_REFERENCES WHERE TAG_NAME = 'PRIVACY_CATEGORY' ORDER BY OBJECT_DATABASE, OBJECT_SCHEMA, OBJECT_NAME, COLUMN_NAME;
特定のデータベース内にあるテーブルまたはビューのシステムタグを持つ列を検索するには、 TAG_REFERENCES Information Schemaテーブル関数を呼び出します。
SELECT * FROM TABLE( my_db.information_schema.tag_references( 'my_db.my_schema.hr_data.fname', 'COLUMN' ) ) ;
特定のデータベース内にあるテーブルまたはビューのすべての列に設定されたすべてのタグを見つけるには、Information Schema TAG_REFERENCES_ALL_COLUMNS テーブル関数を呼び出します。
select * from table( my_db.information_schema.tag_references_all_columns( 'my_db.my_schema.hr_data', 'table' ) ) ;
列の特定のタグ値を見つけるには、 SYSTEM$GET_TAG システム関数を呼び出します。
select system$get_tag( 'snowflake.core.privacy_category', 'hr_data.fname', 'COLUMN' ) ;
次のトピック: