トークナイゼーション
機微なカラムやフィールドのためのフォーマット保持トークナイゼーション。3 つのオンボーディングパスを持つ単一のサービスとして提供されます。
概要
トークナイゼーションは、機微な値 — カード番号、国民 ID、メールアドレス — を、同じ長さと文字構成を持つトークンに置き換えます。これにより、下流のシステムは元の値を一切見ることなく、これまでどおり動作し続けます（クエリ、結合、フォーマット検証など）。DuoKey のトークナイゼーションサービスは、フォーマット保持暗号化（FF1、NIST SP 800-38G 準拠）を実行します。トークン化とデトークン化は、ルックアップテーブルではなく、トークナイゼーション鍵の下での真の逆操作であるため、管理・同期すべき別個のトークン vault は存在しません。
3 つのオンボーディングパスが同じサービスを利用します。
Databricks
クエリ実行時にカラムをトークン化・デトークン化する Spark / Unity Catalog UDF。
Snowflake
Snowflake SQL からカラムをトークン化・デトークン化する外部関数。
トークナイゼーションシークレット
サービスを直接呼び出すアプリケーション向けに、リンクされた vault 内に置かれるスタンドアロンのトークナイゼーション鍵／シークレット。
Databricks バリアントは、生成されるセットアップ SQL も含めてDatabricks ページで詳しく説明されています。このページでは、トークナイゼーションサービス自体と、Snowflake および汎用シークレットのバリアントを扱います。
どのバリアントも同じ tokenize / detokenize エンドポイントと同じ FF1 エンジンを呼び出します — 異なるのはセットアップの成果物（UDF、外部関数、または直接のシークレット）だけです。
トークナイゼーションの仕組み
フォーマット保持
トークンは元の値と同じ長さおよび文字セットを持ちます。16 桁のカード番号は別の 16 桁の並びにトークン化され、メールアドレスは @ とドットの区切り文字を保ちます。
データ型を認識
データ型ヒント（creditcard、ssn、phone、email など）によって適切な文字アルファベットが自動的に選択されます。明示的なフォーマットを固定することもできます。
ドメイン分離
データ型は暗号学的な tweak の一部としても機能するため、同じ平文の値でも 2 つの異なるカラム／ドメインでは異なるトークンになります — カード番号と見た目の似た口座番号が衝突することはありません。
トークン vault を保存しない
トークナイゼーション鍵はテナントごと・名前付き鍵ごとに決定論的に導出されるため、値のデトークン化が、以前に保存された鍵素材の取得に依存することはありません。あるフィールドの保護をローテーションするには、以後に使用する新しい鍵名を選ぶだけです。
| データ型ヒント | 使用されるアルファベット |
|---|---|
| creditcard, ssn, phone, account, numeric | 数字のみ（0–9） — カード番号や電話番号のような数値フォーマットを保持します。 |
| email, iban, name, custom / その他すべて | 大文字小文字混在の英数字 — @ や . などの区切り文字を保持しつつ、それ以外をトークン化します。 |
データ型ヒントから推論されるデフォルトのアルファベットが目的に合わない場合は、データ型の推論に頼らず、明示的なフォーマット（digits、alphanumeric、upper-alpha、lower-alpha およびそれらの派生）を固定できます。
名前付きトークナイゼーション鍵
すべてのトークナイゼーション呼び出しは、テナントにスコープされた鍵を指定します（デフォルトは "default"）。異なる名前付き鍵は暗号学的に独立しているため、次の 2 つの実用的な制御が可能になります。
- セグメンテーション — アプリケーションや環境ごとに異なる名前付き鍵を使用することで、それぞれのトークン化された値が互いに比較可能にならないようにします。
- ローテーション — 新しい鍵名で新しい値のトークン化を開始することで、既存データを期限までに再トークン化する必要なく、そのフィールドの保護を以後についてローテーションできます。
ある鍵名でトークン化された値は、同じ鍵名を指定した場合にのみデトークン化できます。特にローテーションのために新しい鍵名を導入する場合は、どの鍵名がどのカラム／フィールドを保護しているかの対応関係を明確に管理してください。
FPE の tokenize 呼び出しの仕組み
これは、どのバリアントから届いたかにかかわらず、すべての tokenize / detokenize 呼び出しの背後で実際に行われるシーケンスです — Databricks ページのシーケンス図が「DuoKey が鍵を解決し FPE を実行する」とまとめているのと同じステップです。
detokenize はステップ 4 の操作を復号にした、まったく同じシーケンスで実行されます — FF1 はルックアップではなく真の逆操作です。
3 つのバリアント
| バリアント | 利用元 | 固有の設定 |
|---|---|---|
| Databricks | Spark / Unity Catalog UDF | ワークスペース URL、カタログ、スキーマ — 専用の Databricks ページを参照してください。 |
| Snowflake | 外部関数 | Snowflake のアカウント、リージョン、ウェアハウス、データベース、スキーマ、および Snowflake を DuoKey にバインドする API 統合。 |
| トークナイゼーションシークレット | 自社アプリケーションからの直接の API 呼び出し | リンクされた vault 内に作成される名前付きシークレット。独自の鍵タイプ、サイズ、エクスポート可否の設定を持ちます。 |
いずれのバリアントをデプロイする場合も、接続性のヘルスチェック、セルフテスト、監査に使用される DuoKey vault（および任意でその中の鍵）がリンクされます。選択した vault と鍵は統合に対して記録されますが、tokenize/detokenize の呼び出しごとに再選択する必要はありません — これらの呼び出しは、API の権限と指定した名前付き鍵のみによって認可されます。
Snowflake バリアント
Snowflake バリアントをデプロイすると、DuoKey のトークナイゼーションエンドポイントを指す Snowflake の API 統合を作成する SQL と、それを呼び出す TOKENIZE / DETOKENIZE の外部関数を、選択したデータベースとスキーマに作成する SQL が生成されます。
CREATE OR REPLACE API INTEGRATION <integration-name>
API_PROVIDER = aws_api_gateway
API_ALLOWED_PREFIXES = ('<dke-cockpit-origin>/api/apps/tokenization/')
ENABLED = TRUE;
CREATE OR REPLACE DATABASE <database>;
USE DATABASE <database>;
CREATE OR REPLACE SCHEMA <schema>;
CREATE OR REPLACE EXTERNAL FUNCTION <database>.<schema>.TOKENIZE(input VARCHAR) RETURNS VARCHAR
API_INTEGRATION = <integration-name> AS '<dke-cockpit-origin>/api/apps/tokenization/tokenize';
CREATE OR REPLACE EXTERNAL FUNCTION <database>.<schema>.DETOKENIZE(input VARCHAR) RETURNS VARCHAR
API_INTEGRATION = <integration-name> AS '<dke-cockpit-origin>/api/apps/tokenization/detokenize';この Snowflake トークナイゼーションバリアントは、DuoKey for Snowflake（Tri-Secret Secure）と同じ機能ではありません。Tri-Secret Secure は、AWS KMS 上の顧客管理の複合マスターキーによって、Snowflake アカウント全体の保存データを保護します。このトークナイゼーションバリアントは、Snowflake SQL から外部関数として呼び出され、個々のカラムの値をフォーマット保持トークンに置き換えることでそれらを保護します。両者は補完的であり — Tri-Secret Secure によるアカウント全体の暗号化と、特定の機微なフィールドに対するカラムレベルのトークナイゼーションを同時に運用できます — 解決する課題は異なり、それぞれ独立して設定されます。
トークナイゼーションシークレットバリアント
汎用のトークナイゼーションシークレットバリアントは、Databricks や Snowflake にバインドすることなく、選択した vault 内に名前付きのトークナイゼーション鍵を作成します。データプラットフォームの UDF や外部関数を経由せず、自社のアプリケーションがトークナイゼーションサービスを直接呼び出す場合に使用します。
| フィールド | 目的 |
|---|---|
| シークレット名 | リンクされた vault 内に作成されるトークナイゼーション鍵／シークレットの名前。 |
| 鍵タイプ／サイズ | 基盤となる鍵素材のタイプとサイズ（デフォルトは AES-256）。 |
| エクスポート可否 | その鍵を vault からエクスポートできるかどうか。デフォルトはエクスポート不可です。 |
| データ型ヒント | トークナイゼーションのアルファベットを選ぶために使用されるデフォルトのデータ型。 |
| カスタムメタデータ | シークレットに対して記録される任意の自由形式のキー／値タグ。 |
ヘルスチェックとセルフテスト
どのバリアントも、リンクされた vault に対して解決される同じヘルスチェックとセルフテストの機能を公開します。ヘルスチェックは vault への到達性（および判定可能な場合は認証）を報告し、セルフテストはさらに、シミュレートされた結果ではなく、vault に対する実際の往復 — Databricks の場合はワークスペースへの到達性のライブプローブも — を実行します。