分類の紹介¶
このトピックでは、分類のしくみに関する情報を提供します。
このトピックの内容:
概要¶
分類は、個人データのセルとメタデータを分析することにより、Snowflakeで定義されたタグ(つまり、システムタグ)を列に関連付ける多段階プロセスです。データエンジニアはこのデータを追跡できるようになりました。
追跡情報と関連する監査プロセスに基づいて、データエンジニアは個人データや機密データを含む列をマスキングポリシーで保護したり、この列を含むテーブルを行アクセスポリシーで保護したりできます。
分類およびデータ保護ステップの全体的な結果は、データプライバシー規制への準拠を促進することです。
プロセス¶
このセクションでは、分類の3段階のプロセスがどのように機能するかについて説明します。このプロセスは、テーブルに新しい行を挿入した後やテーブルに新しい列を追加した後など、必要に応じて何度でも繰り返すことができます。
分類は、分析、レビュー、適用という3段階のプロセスに簡素化されます。これらの各ステップには、異なる操作があります。
- 分析
データエンジニアは、Snowflakeアカウントで EXTRACT_SEMANTIC_CATEGORIES 関数を呼び出します。この関数は、テーブル内の列を分析し、使用可能なカテゴリおよび関連するメタデータを出力します。詳細については、 出力を解釈する (このトピック内)をご参照ください。
注釈
複数のオブジェクトに対して JOIN 操作を必要とするビューなどの複雑なビュー定義は、分析プロセスを遅くする可能性があります。複雑なビューを分類する前に、稼働中のウェアハウスを検討してください。詳細については、 コンピューティングコスト (このトピック内)をご参照ください。
- レビュー
レビューのステップでは、データエンジニアがカテゴリの結果をレビューして、分析ステップ操作の結果が意味を成すことを確認します。修正が必要ない場合、データエンジニアは適用ステップに進むことができます。
修正が必要な場合、データエンジニアは適用ステップに進む前に分析ステップの出力を修正できます。
詳細については、 出力を解釈する (このトピック内)をご参照ください。
- 適用
適用ステップには、システムタグの割り当てという1つの操作があります。
データエンジニアは、列にシステムタグを手動で設定するか、 ASSOCIATE_SEMANTIC_CATEGORY_TAGS ストアドプロシージャを呼び出すことができます。
システムタグを割り当てた後、データエンジニアは システムタグを追跡 し、マスキングポリシーまたは行アクセスポリシーを使用して個人データや機密データを保護できます。
このプロセスの詳細な例については、 データ分類を使用する をご参照ください。
システムタグおよびカテゴリ¶
システムタグは、Snowflakeが共有 SNOWFLAKE データベース で作成、維持、および利用できるようにするタグです。2つの分類システムタグがあり、どちらも SNOWFLAKE.CORE
スキーマに存在します。
SNOWFLAKE.CORE.SEMANTIC_CATEGORY
SNOWFLAKE.CORE.PRIVACY_CATEGORY
データエンジニアは、個人データまたは機密データを含む列にこれらのタグを割り当てます。
- 文字列値
Snowflakeは、列でのシステムタグの割り当てをキーと値のペアとして保存します。値は文字列です。Snowflakeはこれらの各システムタグを維持するため、Snowflakeは各分類システムタグに許可される文字列値を定義します。
タグ名 SEMANTIC_CATEGORY
および PRIVACY_CATEGORY
は、列サンプリングプロセス中にSnowflakeが列データに割り当てる、分類カテゴリに対応します(つまり、タグ名とカテゴリ名は同じ単語を使用します)。
- セマンティックカテゴリ
セマンティックカテゴリは、個人の属性を識別します。
分類がサポートする個人属性の非網羅的なリストには、名前、年齢、性別が含まれます。これら3つの属性は、
SEMANTIC_CATEGORY
タグを列に割り当てるときに使用可能な文字列値です。分類により、オーストラリア、カナダ、英国など、さまざまな国から情報を検出することができます。たとえば、テーブルの列に電話番号の情報が含まれている場合、分析プロセスでは、それぞれの国の異なる電話番号の値を区別することができます。サポートされる国際化の値の包括的なリストについては、 国際化タグ値を持つシステムタグ (このトピック内)をご参照ください。
- プライバシーカテゴリ
分析により、列データがセマンティックカテゴリに対応すると判断された場合、Snowflakeはさらに列をプライバシーカテゴリに分類します。プライバシーカテゴリには、識別子、準識別子、機密の3つの値があります。これら3つの値は、
PRIVACY_CATEGORY
分類システムタグを列に割り当てるときに指定できる文字列値です。識別子: これらの属性は、個人を一意に識別します。属性の例には、名前、社会保障番号、電話番号などがあります。
識別子属性は 直接識別子 と同義です。
準識別子: これらの属性は、2つ以上の属性が組み合わされた場合に、個人を一意に識別することができます。属性の例には、年齢と性別が含まれます。
準識別子は 間接識別子 と同義です。
機密: これらの属性は、個人を識別するのに十分とは見なされませんが、個人がプライバシー上の理由で開示を望まない情報です。
現在、Snowflakeが機密と評価する唯一の属性は給与です。
次のテーブルは、各分類カテゴリとシステムタグの関係、および各分類システムタグの文字列値をまとめたものです。このテーブルの行は、国際化の値を 持たない カテゴリのサポートを示しています。
|
|
---|---|
|
|
|
|
|
|
注釈
3つのプライバシーカテゴリすべてからの複数のセマンティックタグ文字列値は、「機密性の高い個人データ」、「データの特別なカテゴリ」、または法規制に基づく同様の用語と見なされ、追加の保護または制御が必要になる場合があります。
現在、分類では、列データに機密性と識別性の両方のタグが付けられていません。つまり、特定の列にシステムタグを設定する場合は、 SEMANTIC_CATEGORY または PRIVACY_CATEGORY タグのいずれかを選択する必要があります。
国際化タグ値を持つシステムタグ¶
Snowflakeは、オーストラリア、カナダ、ニュージーランド、スイス、英国、米国に関連する国際化 SEMANTIC_CATEGORY タグ値をサポートしています。これらの国をサポートするために、タグの値は特定の 親カテゴリグループ に対応しています。親カテゴリには、その列の大半が1つの国の値で構成されているか、別の国の値で構成されているかなど、分類結果に関する情報が含まれます。
次のテーブルは、分類タグ、カテゴリグループ、グループメンバー、およびサポート対象国間の関係をまとめたものです。国名コードは、 ISO-3166-1 alpha-2 規格に基づいています。EMAIL や GENDER のような他のセマンティックカテゴリは影響を受けません。国際情報を追跡するために、データエンジニアは、システムタグを列に設定するときに、 SEMANTIC_CATEGORY タグ値列の値を使用します。
PRIVACY_CATEGORY タグ値 |
SEMANTIC_CATEGORY タグ値(親グループ) |
グループメンバー |
国名コード |
---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
出力を解釈する¶
以下は、 データ分類を使用する に示されている 単一のテーブルを分類する の例を簡略化した例です。
テーブルを作成します。
CREATE OR REPLACE TABLE hr_data ( age INTEGER, email_address VARCHAR, fname VARCHAR, lname VARCHAR );
テーブルにデータをロードしてから、 EXTRACT_SEMANTIC_CATEGORIES 関数を呼び出します。
INSERT INTO hr_data (fname, lname, age, email_address) VALUES ('Thomas', 'Smith', 44, 'TS_NoAdvertising@SpamFilter.com'), ('Katherine', 'Lee', 29, 'KL_JunkMailFolder@GatingEmail.com'), ('Lisa', 'Curie', 29, 'LC_03@GatingEmail.com'), ('Albert', 'Meitner', 14, 'AM_bucket@GatingEmail.com'), ('Horace', 'Jones', 53, 'HJ_track@SpamFilter.com'), ('Natalia', 'Chavez', 38, 'NataliaC@DoNotTrack.org');
USE ROLE data_engineer; SELECT EXTRACT_SEMANTIC_CATEGORIES('hr_data');
デフォルトの出力を評価します。例:
+-----------------------------------------------+ | EXTRACT_SEMANTIC_CATEGORIES('HR_DATA') | |-----------------------------------------------| | { | | "AGE": { | | "alternates": [], | | "recommendation": { | | "confidence": "HIGH", | | "coverage": 1, | | "details": [], | | "privacy_category": "QUASI_IDENTIFIER", | | "semantic_category": "AGE" | | }, | | "valid_value_ratio": 1 | | }, | | "EMAIL_ADDRESS": { | | "alternates": [], | | "recommendation": { | | "confidence": "HIGH", | | "coverage": 1, | | "details": [], | | "privacy_category": "IDENTIFIER", | | "semantic_category": "EMAIL" | | }, | | "valid_value_ratio": 1 | | }, | | "FNAME": { | | "alternates": [], | | "recommendation": { | | "confidence": "HIGH", | | "coverage": 1, | | "details": [], | | "privacy_category": "IDENTIFIER", | | "semantic_category": "NAME" | | }, | | "valid_value_ratio": 1 | | }, | | "LNAME": { | | "alternates": [], | | "recommendation": { | | "confidence": "HIGH", | | "coverage": 1, | | "details": [], | | "privacy_category": "IDENTIFIER", | | "semantic_category": "NAME" | | }, | | "valid_value_ratio": 1 | | } | | } | +-----------------------------------------------+
FLATTEN テーブル関数を使用して読みやすくします。
SELECT f.key::varchar as column_name, f.value:"recommendation":"privacy_category"::varchar as privacy_category, f.value:"recommendation":"semantic_category"::varchar as semantic_category, f.value:"recommendation":"confidence"::varchar as confidence, f.value:"recommendation":"coverage"::number(10,2) as coverage, f.value:"details"::variant as details, f.value:"alternates"::variant as alternates FROM TABLE(FLATTEN(EXTRACT_SEMANTIC_CATEGORIES('hr_data')::VARIANT)) AS f;
+---------------+------------------+-------------------+------------+----------+---------+------------+ | COLUMN_NAME | PRIVACY_CATEGORY | SEMANTIC_CATEGORY | CONFIDENCE | COVERAGE | DETAILS | ALTERNATES | |---------------+------------------+-------------------+------------+----------+---------+------------| | AGE | QUASI_IDENTIFIER | AGE | HIGH | 1.00 | NULL | [] | | EMAIL_ADDRESS | IDENTIFIER | EMAIL | HIGH | 1.00 | NULL | [] | | FNAME | IDENTIFIER | NAME | HIGH | 1.00 | NULL | [] | | LNAME | IDENTIFIER | NAME | HIGH | 1.00 | NULL | [] | +---------------+------------------+-------------------+------------+----------+---------+------------+
サポートされているオブジェクトおよび列のデータ型¶
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' ) ;
次のトピック: