分類の紹介¶

プロセス¶

このセクションでは、分類の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は各分類システムタグに許可される文字列値を定義します。

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');

Copy

タグ名 SEMANTIC_CATEGORY および PRIVACY_CATEGORY は、列サンプリングプロセス中にSnowflakeが列データに割り当てる、分類カテゴリに対応します（つまり、タグ名とカテゴリ名は同じ単語を使用します）。

セマンティックカテゴリ

セマンティックカテゴリは、個人の属性を識別します。

分類がサポートする個人属性の非網羅的なリストには、名前、年齢、性別が含まれます。これら3つの属性は、 SEMANTIC_CATEGORY タグを列に割り当てるときに使用可能な文字列値です。

プライバシーカテゴリ

分析により、列データがセマンティックカテゴリに対応すると判断された場合、Snowflakeはさらに列をプライバシーカテゴリに分類します。プライバシーカテゴリには、識別子、準識別子、機密の3つの値があります。これら3つの値は、 PRIVACY_CATEGORY 分類システムタグを列に割り当てるときに指定できる文字列値です。

• 識別子: これらの属性は、個人を一意に識別します。属性の例には、名前、社会保障番号、電話番号などがあります。

  識別子属性は 直接識別子 と同義です。

• 準識別子: これらの属性は、2つ以上の属性が組み合わされた場合に、個人を一意に識別することができます。属性の例には、年齢と性別が含まれます。

  準識別子は 間接識別子 と同義です。

• 機密: これらの属性は、個人を識別するのに十分とは見なされませんが、個人がプライバシー上の理由で開示を望まない情報です。

  現在、Snowflakeが機密と評価する唯一の属性は給与です。

次のテーブルは、各分類カテゴリとシステムタグの関係、各分類システムタグに使用できる文字列値、および各システムタグのシステムタグ文字列値をまとめたものです。

分類出力の解釈¶

EXTRACT_SEMANTIC_CATEGORIES 関数は、半構造化形式である JSON 形式の次を含む VARIANT を返します。

• 0.8を超えるの可能性のあるセマンティックおよびプライバシーカテゴリは、 extra_info の外側にリストされ（EXTRACT_SEMANTIC_CATEGORIES 関数を参照）、 ASSOCIATE_SEMANTIC_CATEGORY_TAGS ストアドプロシージャによって適用されるものでもあります。

• 分類プロセスが正しいセマンティックカテゴリを導き出した確率。

• 列にタグを付けることができる代替セマンティックカテゴリのリスト（確率が 0.80 しきい値を下回り、プロセスが 0.15 より大きい確率で他の可能なセマンティックカテゴリを識別する場合）。ただし、これらの値を使用するには、データエンジニアがシステムタグを手動で設定するか、出力を修正する必要があります。

確率値は、列に個人データまたは機密データが含まれているかどうかについて、データエンジニアが十分な情報に基づいて決定するのに役立ちます。確率が高いほど、列に含まれている可能性が高くなります。

以下は、 データ分類の使用 に示されている 単一のテーブルを分類する の例を簡略化した例です。

1. テーブルを作成します。

   CREATE TABLE hr_data (
       age INTEGER,
       email_address VARCHAR,
       fname VARCHAR,
       lname VARCHAR
       );
   

   Copy

2. テーブルにデータをロードしてから、 EXTRACT_SEMANTIC_CATEGORIES 関数を呼び出します。

   USE ROLE data_engineer;
   
   SELECT EXTRACT_SEMANTIC_CATEGORIES('hr_data');
   

   Copy

3. 出力を評価します。例:

   デフォルトの出力:

   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"             |
   |   }                                         |
   | }                                           |
   +---------------------------------------------+
   

   Copy

   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 | []         |
   +---------------+------------------+-------------------+-------------+------------+
   

   Copy

   一部のフィールド（例: PROBABILITY フィールド）にある値は、データの特性とサンプルサイズによって異なることに注意してください。

サポートされているオブジェクトおよび列のデータ型¶

Snowflakeは、外部テーブル、マテリアライズドビュー、セキュアビューなど、すべての型のテーブルとビューに保存されているデータの分類をサポートしています。

サポートされているすべての データ型 のテーブルとビューの列を分類できます。ただし、次のデータ型は 除きます。

• GEOGRAPHY

• BINARY

• VARIANT

  列のデータ型を NUMBER または STRING データ型に キャスト できる場合は、列を VARIANT データ型で分類できることに注意してください。列に JSON、 XML、またはその他の半構造化データが含まれている場合、Snowflakeは列を分類しません。

テーブルにサポートされているデータ型ではない列が含まれている場合、または列にすべての NULL 値が含まれている場合、分類プロセスは列を無視し、出力に含めません。

コンピューティングコスト¶

分類プロセスには、分類が実行されるときに使用および実行されている、 仮想ウェアハウス によって提供されるコンピューティングリソースが必要です。

テーブル/ビュー内のデータを分類するために必要な時間（したがって、ウェアハウスによって消費されるクレジットの数）は、分類されるデータの量の関数です。

特に、テーブル/ビューに分類をサポートする列が多数ある場合は、処理時間に影響を与える可能性があります。ただし、原則として、処理速度はウェアハウスのサイズに比例します。言い換えると、ウェアハウスのサイズが大きくなるごとに（例: XSからS）、通常、処理時間が半分に短縮されます。

次の一般的なガイドラインに従って、 ウェアハウスのサイズ を選択します。

• 処理時間の考慮なし: XSウェアハウス。

• テーブル内の列が最大100列: Sウェアハウス。

• テーブル内の列が101列から300列: Mウェアハウス。

• テーブル内の列が301列以上: Lウェアハウス。

利点¶

分類は、データのプライバシーとデータガバナンスの管理者に次の利点を提供します。

データアクセス

列データを分類した結果は、IDおよびアクセス管理の管理者に、Snowflakeの ロール階層 を評価および維持して、Snowflakeのロールが機密データまたは PII データへの適切なアクセス権を確保するように通知できます。

データ共有

分類プロセスは、 PII データのストレージの場所を特定して確認するのに役立ちます。その後、データ共有プロバイダーは分類結果を使用して、データを共有するかどうか、またデータ共有コンシューマーが PII データを利用できるようにする方法を決定できます。

ポリシーの適用

ベーステーブル内の列を参照してビューまたはマテリアライズドビューを作成するなど、 PII データを含む列を使用すると、マスキングポリシーまたは行アクセスポリシーのいずれかを使用してデータを保護するための最適なアプローチを決定するのに役立ちます。

権限リファレンス¶

次のテーブルは、分類の 分析と確認のステップ に最低限必要な権限をまとめたものです。

分類での 適用ステップ、特に システムタグの設定 に必要な権限は、選択したアプローチによって異なります。現在、次の3つのオプションがあります。

• GOVERNANCE_ADMIN データベースロールを使用します。

• IMPORTED PRIVILEGES をカスタムロールに付与します。

• ACCOUNTADMIN ロールを使用します。

データベースロール

データベースロールのアプローチでは、 GOVERNANCE_ADMIN データベースロール を使用して、テーブル列に分類システムタグを設定します。さらに、データエンジニアには、所有していないオブジェクトにタグを設定するための APPLY TAG グローバル権限があります。

これを実行するには、

1. 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;
   

   Copy

2. テーブル列にシステムタグを割り当てます。たとえば、 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';
   

   Copy

データベースロールのアプローチを使用すると、プリンシパルの最小権限の要件を満たすことができます。

カスタムロール

カスタムロール（つまり、作成するアカウントレベルのロール）のアプローチでは、選択したロールに2つの権限を付与する必要があります。例:

use role accountadmin;
grant imported privileges on database snowflake to role data_engineer;
grant apply tag on account to role data_engineer;

Copy

これら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;
  

  Copy

• 特定のデータベース内にあるテーブルまたはビューのシステムタグを持つ列を検索するには、 TAG_REFERENCES Information Schemaテーブル関数を呼び出します。

  SELECT * FROM
    TABLE(
      my_db.information_schema.tag_references(
        'my_db.my_schema.hr_data.fname',
        'COLUMN'
      )
    )
  ;
  

  Copy

• 特定のデータベース内にあるテーブルまたはビューのすべての列に設定されたすべてのタグを見つけるには、Information Schema TAG_REFERENCES_ALL_COLUMNS テーブル関数を呼び出します。

  select * from
    table(
      my_db.information_schema.tag_references_all_columns(
        'my_db.my_schema.hr_data',
        'table'
      )
    )
  ;
  

  Copy

• 列の特定のタグ値を見つけるには、 SYSTEM$GET_TAG システム関数を呼び出します。

  select system$get_tag(
    'snowflake.core.privacy_category',
    'hr_data.fname',
    'COLUMN'
    )
  ;
  

  Copy

次のトピック:

• データ分類の使用