購入ガイド ·Vaultless Tokenization
Vaultless （Tokenization ）はどれも同じというわけではない
Vaultless プラットフォームから何が削除されたかを説明しています。何がそれに取って代わったかについては説明していません。
公開日：2026年9月16日 · 更新日：2026年9月16日 ·Rixon テクノロジー · 読了時間：12分
Vaultless tokenization tokenization は、元の機密値とその との関連性を保存するために、一元化されたデータベースを使用しないものです。tokenこのvault を排除することで 、重大な集中リスクを軽減することができます。 しかし、 は、プラットフォームに「何がないか」を示す記述に過ぎず、購入者はプラットフォームに「何があるか」を知る必要があります。vaultless
Vaultless 各プラットフォームは、tokens の生成方法、復旧を可能にする仕組み、暗号化されたkeys が必要かどうか、変換がどこで行われるか、顧客の分離方法、ポリシーの管理主体、製品が購入予定の別のプラットフォームと連動しているかどうか、そして組織が展開モデルやプロバイダーをどれほど容易に変更できるかといった点において、大きく異なります。
たった一つの質問
vault が存在しない場合、復元はどのように可能になるのでしょうか。また、攻撃者が元のデータを取得するには、何を侵害しなければならないのでしょうか。
このガイドのそれ以外の内容はすべて、その質問から派生したものです。この質問に明確に答えるプロバイダーは、アーキテクチャを説明しているのです。一方、「vaultless」という言葉で答えるプロバイダーは、マーケティング上のカテゴリーを説明しているに過ぎません。
このガイドの内容
KEY 要点
vault を削除することで、ある種の集中リスクを軽減することができます。ただし、それだけでは、そのプラットフォームが暗号化を採用しているか（keys ）、オフラインでの取り消しが可能か、処理インフラを共有しているか、回復リクエストのたびにポリシーを評価しているか、あるいは顧客を特定のクラウド（key ）、管理システム、決済処理パートナー、データプラットフォームに縛り付けているかといった点は明らかになりません。
Vaultless これは評価の結論ではなく、その始まりとして捉えるべきである。
vaultless とtokenization はすべて同じものですか？
Vaultless は、あるコンポーネントに関する単一のアーキテクチャ上の事実です。この事実を共有するプラットフォームであっても、セキュリティやコンプライアンスの審査において重要なその他のほぼすべての点で異なる場合があります。
従来のtokenization では、通常、token （vault ）が使用されます。vault には、元の機密値と、それを置き換えるtoken との関連性が保存されます。例えば：
元の値：
4111 1111 1111 1111
Token:
9274 5186 3021 7742
元の値が必要な場合、システムは「vault 」内の「token 」を検索し、対応するデータを返します。このアーキテクチャは効果的ですが、「vault 」は標的として高い価値を持つことになります。そこには、大量の機密データや、元の値を復元することを可能にするマッピングが格納されている可能性があるからです。
Vaultless tokenization その一元化されたマッピングデータベースを排除します。保存されているtoken と値の対応関係を検索する代わりに、このプラットフォームは別の方法を用いて元の値をtoken に変換し、権限が認められている場合にはそれを復元します。これは重要なアーキテクチャの変更であり、このガイドの核心となる疑問を即座に提起します。すなわち、vault が存在しない場合、何が復元を可能にするのでしょうか？
プロバイダーによっては、その回答には、暗号化keys 、顧客が管理する暗号素材、フォーマット保持型暗号化、key 管理システム、独自アルゴリズム、特定のデータプラットフォーム、共有クラウドサービス、専用の翻訳エンジン、あるいは顧客がホストするランタイムなどが含まれる場合があります。これらの回答のそれぞれが、異なる信頼モデル、運用負担、およびセキュリティ境界を生み出します。
比較：vault ベース、vaultless key ベース、およびvaultless keyless
この比較は、vaultless との対比として行われているわけではありません。これは3者間の比較です。というのも、「vaultless 」として販売されているプラットフォームのほとんどは、依然として暗号化されたkey に依存しているからです。
| 評価基準 | Vault-ベースtokenization | Vaultless,key に基づく | Vaultless およびkeyless （Rixon のアプローチ） |
|---|---|---|---|
| その代わりとなるのはvault | 特にありません。token と値の対応関係は、一元化されたデータベースに保存されています。 | アルゴリズムに加え、暗号keys または保護された暗号素材。 | ポリシー評価済みのリクエストによって呼び出される翻訳処理。 |
| 回復を可能にするもの | 保存されているマッピングに対する検索。 | プロバイダーまたは顧客が保有するkey を使用した復号、またはkey に基づく導出。 | 顧客専用のエンジンに対する承認済みのリクエストで、データ所有者の有効なポリシーに基づいて評価されたもの。 |
| key の暗号関連の依存関係 | 一般的に言えば、はい。vault のコンテンツを保護するためです。 | はい。セキュリティは、key の管理、ローテーション、バックアップ、および特権アクセスに依存しています。 | 従来の暗号化keys は、token を導出したり復元したりするために使用されるものではありません。 |
| KMS（HSM ）が必要です | 一般的に。 | 一般的に。実装によっては、HSM や専用のアプライアンスが必要になる場合があります。 | 不要です。 |
| 盗難に遭ったtoken ストアのオフラインでの取引取り消し | tokens だけでは利用できません。vault へのアクセスが必要です。 | 攻撃者が「key 」または「key 」の資料も入手している場合には、この攻撃が可能となる可能性があります。各プロバイダーに直接お問い合わせください。 | 復旧には有効な承認済みリクエストが必要であるため、盗まれたtoken ストアだけでは取り消しの手段とはなりません。 |
| フォーマットの取り扱い | Token このフォーマットは、vault スキーマによって定義されています。 | 一般に「フォーマット保持暗号化」と呼ばれるもので、これはtokenization ではなく、暗号化そのものです。 | key に基づく暗号文を表現することなく、既存のスキーマに適合するように設計された、フォーマット互換のtokens 。 |
| 賃貸モデル | 状況により異なります。多くの場合、インフラは共有されています。 | ケースバイケースです。多くの場合、複数の顧客間で処理を共有しています。 | お客様ごとに専用のエンジンを用意しています。複数の顧客のデータを1つのエンジンで変換することはありません。 |
| すべての復旧リクエストに対してポリシーが評価される | 実装によって異なります。 | ケースによって異なります。設計によっては、有効なkey またはセッションによって、常時有効な復旧用アクセス権が作成される場合があります。 | はい、成功したリクエストと失敗したリクエストはそれぞれ個別にログに記録されます。 |
| 他の製品との連携 | ケースによって異なります。ゲートウェイや処理上の関係に紐づく場合もあります。 | 状況により異なります。特定のデータプラットフォーム、レイクハウス、クラウド、またはKMSに固有のものもあります。 | 不要です。特定のクラウド、データプラットフォーム、KMS、または専用ハードウェアは不要です。 |
| 導入オプション | 一般的に管理されるSaaS。 | ケースバイケースです。SaaS、セルフマネージド、またはホストプラットフォームにネイティブに組み込まれているものなどがあります。 | 標準ではマネージドSaaSまたは顧客のクラウドを採用しています。ハイブリッド構成も利用可能です。オンプレミスについては、デフォルトではなく、状況に応じてサポートされます。 |
| 集中リスクの動向 | vault そのものへ。 | key およびkey の管理環境へ。 | 復旧ポリシーおよびそれを呼び出す権限を持つ認証情報について。 |
「vault 」ベースおよび「key 」ベースのアーキテクチャに関する項目は、特定のベンダーではなく、このカテゴリー全体に共通するパターンを記述したものです。実装内容は様々であるため、購入を検討される方は、評価対象のプロバイダーに各項目について直接確認してください。
RIXON回答の概要
回復を可能にするものは何でしょうか？
顧客専用のエンジンに対する、リアルタイムで承認済みかつポリシー評価済みのリクエスト。
従来の暗号化keys は、token を復号するために使用されるのでしょうか？
いいえ。token 自体については、盗んだり、入れ替えたり、預託したりできるような従来の暗号化機能key は存在しません。
tokens はどこに生息しているのでしょうか？
顧客環境において、翻訳機能とは切り離された状態で。
処理は顧客間で共有されていますか？
いいえ。各顧客は専用のエンジンを通じて動作します。
Rixon は、クラウド、データプラットフォーム、プロセッサ、あるいはHSM のいずれかと連携していますか？
いいえ。マネージドSaaSと顧客のクラウドが標準モデルであり、ハイブリッドも利用可能ですが、オンプレミスについてはケースバイケースで検討されます。
Rixon 独自の集中リスクはどの程度あるのでしょうか？
回復ポリシーおよびそれを呼び出す権限が与えられた認証情報において、これが、ポリシーの所有権とリクエストごとのログ記録が重要となる理由です。
Vaultless …という意味ではないkeyless
Vaultless また、「keyless 」は別の主張です。プラットフォームは、token vault を削除しても、tokens の生成と復元には、依然として暗号技術key に完全に依存することができます。
これらの用語は、同じ意味であるかのように扱われることがありますが、実際には異なります。key に基づくアーキテクチャでは、セキュリティは、暗号化keys 、key 管理システム、ハードウェアセキュリティモジュール、管理者アクセス、key ローテーションおよびバックアップ手順、暗号実装、復旧用認証情報、および特権オペレーターの保護に依存する場合があります。
適切に実装された暗号技術とkey 管理は、強力な保護を提供することができます。問題は、そのアーキテクチャが自動的に安全でないということではありません。問題は、そのアーキテクチャには、購入者が特定し評価する必要があるセキュリティ上の依存関係が残っており、それが「vaultless 」という言葉によって隠蔽されているという点にあります。
keyless のアプローチは、これとは異なる道筋をたどります。このアプローチでは、保護された値を導出または復元するために、従来の暗号化key に依存することを避けます。これにより、購入者にとってのセキュリティ上の核心的な疑問は、「 keys はどのように保護されているか？」から、「各復元リクエストはどのように承認、評価、隔離、および監査されているか？」へと変わります。
その主張を検証する方法
プロバイダーに対し、detokenization を一連の操作として説明するよう依頼してください。その一連の操作に、key を使用して行われる復号化のステップが含まれている場合、そのプラットフォームはvaultless およびkey を基盤としています。これは正当なアーキテクチャであり、そのように評価されるべきです。
「token 」が示す本来の価値とは
token の漏洩の程度は、2つの特性によって決まります。それは、元の値の一部が平文のまま内部に保持されているかどうか、および同じ入力が常に同じtoken を生成するかどうかです。
内の平文の断片token
一部の設計では、下流のシステムがtoken を認識できるように、元の値の一部を意図的に保持しています。一般的なパターンとしては、支払いカードの先頭桁と末尾4桁を保持し、中間部分のみをトークン化して、長さと形式が変わらないように結果を再構成する方法があります。これは領収書やカスタマーサービスにおいて有用であるだけでなく、設計上、推論の根拠ともなります。というのも、保持された部分からissuer 、製品タイプ、そして多くの場合、国を特定できるからです。
購入者は、元の値の一部がtoken 内に平文で保持されているかどうか、その動作がデータ要素ごとに設定可能かどうか、およびプロバイダーが自社のドキュメントにおいてそれらの保持部分をどのように扱っているかを確認する必要があります。
決定論的か、あるいはランダム化か
決定論的なtoken は、同じ入力に対して毎回同じ結果となります。これこそがtokens を結合可能にする要因であり、これにより、元の値を復元することなく、システム間でレコードの照合、重複排除、分析を行うことが可能になります。また、これは等価性が保たれることを意味し、等価性そのものが情報となります。支払いカード番号の場合、カーディナリティが十分に高いため、この点はほとんど問題になりません。 ステータスコード、郵便番号、国、生年など、取り得る値が少ないフィールドの場合、個々の値token を復元できない場合でも、決定論的なtokens を持つ列であれば、頻度分析を行うことが可能です。
ランダム化されたtoken は、そのリークを排除すると同時に、結合可能性も排除してしまいます。一般的に言えば、どちらの設定も正しくありません。重要なのは、プラットフォームがデータ所有者にデータ要素ごとに選択を許可しているかどうかです。そうすれば、参照整合性が必要なフィールドと、機密属性を含む低カーディナリティのフィールドが、同じ設定に強制されることを防げます。
原則
結合性と等価性の漏れは、同じ特性を異なる側面から見たものです。いずれか一方を提供するプラットフォームは、もう一方も提供していることになります。ここで問うべきは、誰が、どのような粒度で決定するのか、ということです。
攻撃者は何を侵害しなければならないのか？
tokenization の各プラットフォームを比較する上で最も重要な点は、機密データを復元するために攻撃者が何を入手する必要があるか、そして一度の侵害だけで十分かどうかという点である。
クライアント側のセキュリティ侵害
攻撃者が、tokens を含むデータベースへのアクセス権を取得したと仮定する。購入者は、tokens を保有することでオフライン攻撃が可能になるかどうか、token に暗号化された情報が埋め込まれているかどうか、攻撃者がtoken を盗んだkey と組み合わせることができるかどうか、同じ環境で復旧機能が利用可能かどうか、攻撃者が別のサービスへのアクセスも必要とするかどうか、そして復旧リクエストが依然として有効なポリシーに基づいて評価されるかどうかを確認すべきである。
token は、一見ランダムに見えるという理由だけで安全であると見なすべきではありません。その安全性は、作成に使用された手法と、復元を管理する制御措置によって決まります。
プロバイダー側のセキュリティ侵害
購入者はまた、tokenization のプロバイダーやランタイムが侵害された場合、攻撃者がどのような情報を入手できるかについても確認すべきです。具体的には、元の値が保存されているか、token と値のマッピングが保持されているか、暗号化されたkeys が存在するか、同一の環境で複数の顧客が処理されているか、1つの管理者アカウントで複数のテナントにアクセスできるか、トランザクション終了後もランタイムにデータが残留するか、そして攻撃者が顧客が保有するtokens を入手せずにサービスを利用できるかどうか、といった点です。
tokens の分離と回収能力
tokens が顧客環境に保存されており、それらを復元するために必要な機能が別の管理された環境にある場合、攻撃者は通常、双方を侵害する必要があります。クライアント側の侵害が発生しても、復元機能は漏洩せずに、tokens が漏洩する可能性があります。一方、復元環境が侵害された場合、顧客のtoken データベース全体、元の値、またはtoken のマッピングを保持していないサービスが漏洩する可能性があります。
購入者は、tokens がどこに保存されているか、変換がどこで行われるか、これら2つの環境が独立して管理されているか、復元サービスが元の値を保持しているか、token をライブリクエストなしで復元できるか、すべての復元リクエストがポリシーに基づいて評価されるか、および成功したリクエストと失敗したリクエストがログに記録されるかについて評価する必要があります。重要なのは、vault が存在するかどうかだけではありません。重要なのは、そのアーキテクチャが、単一の侵害によって保護されたデータとそれを復元する手段の両方が漏洩することを防いでいるかどうかです。
復旧はセキュリティインシデントとして扱うべきである
tokenization に関する評価の多くは、token がどのように生成されるかに焦点を当てています。しかし、より重要な問いは、誰が、どのような条件下で元の値を復元できるのか、そしてその要求によってどのような痕跡が残されるのか、ということです。
堅牢な回復モデルでは、ユーザーやアプリケーションがログインしているかどうかだけでなく、さらに多くの要素を評価する必要があります。ポリシーでは、ユーザーの役割、アプリケーションの識別情報、ワークロードの識別情報、ソースシステム、IPアドレス、地理的情報、デバイス、時間帯、有効期間、環境、業務目的、二次認証、およびレコードレベルの権限などを考慮に入れることができます。
また、すべての復旧要求については、監査証拠を生成する必要があります。具体的には、誰がその値を要求したか、どのアプリケーションが要求を行ったか、いつ発生したか、どこから発信されたか、どの保護対象レコードが関係していたか、どのポリシーが適用されたか、要求が成功したか失敗したか、そして異常な動作が検出されたかどうかの情報です。これにより、従来のインフラストラクチャ監視では得られないような、データ要素レベルのアクセス信号が生成されます。
原則
有効なログインによって、保護されたすべての値を回復するための恒久的な権限が付与されるべきではない。
テナントの孤立および集中リスク
Vaultless プラットフォームによって、顧客が処理インフラを共有するかどうかは異なります。ランタイムが共有されている場合、単一の環境が侵害された際の被害の大きさが増大します。
サービスによっては、共有インフラストラクチャを通じて複数の顧客に対応しているものもあります。また、顧客が自らホストする形での導入を許可しているサービスもあります。さらに、顧客ごとに専用のエンジンやランタイムを使用しているサービスもあります。
購入者は、処理が顧客間で共有されているか、メモリが共有されているか、管理制御が共有されているか、あるテナントの設定が別のテナントに影響を与える可能性があるか、テナント間の直接的な接続経路が存在するか、顧客環境が論理的または物理的に分離されているか、顧客データを保持せずにランタイムを再構築できるか、および管理アカウントが侵害された場合の被害範囲はどの程度になるか、といった点を確認すべきである。
専用の処理環境を構築することで、テナント間のリスクへの曝露を軽減し、1つのランタイムが侵害された場合の被害を限定することができます。シングルテナントであるという事実だけでは、セキュリティは保証されません。ID管理、ソフトウェアの完全性、クラウドのアクセス権限、監視、API の制御、そして運用上の規律は、依然として重要です。テナントの分離は、アーキテクチャの一部として評価されるべきであり、「vaultless 」という言葉から自動的に保証されていると想定すべきではありません。
お持ちのtokenization は、ご購入予定の別の製品とセットになっていますか？
Tokenization 多くの場合、何か他の機能の一部として提供されます。結合は妥当な場合もありますが、将来の選択肢を狭めてしまうため、実装前に特定しておくべきであり、更新時に初めて発見されるような事態は避けるべきです。
市場では3種類の連結方式が一般的であり、それぞれによって購入者のレバレッジが変化します。
決済処理の取引関係と結びついている
一部のtokenization は、処理契約の一環として、ゲートウェイ、プロセッサー、acquirer 、またはカードネットワークを通じて提供されます。この方法で発行されたTokens は、通常、そのプロバイダーのエコシステム内でのみ有効です。購入者は、処理契約が変更された場合でもtokens が引き続き使用可能かどうか、同じtokens が複数のプロセッサーやチャネルで機能するかどうか、またプロセッサーを変更する際に保存済みのデータ資産の再トークン化が必要になるかどうかを確認する必要があります。
データプラットフォームまたはレイクハウスと連携して
一部のtokenization は、特定のデータプラットフォーム、分析環境、またはレイクハウス内でネイティブに実行され、そのプラットフォーム独自のkey 管理・ガバナンスツールと連携します。これは、すでにそのプラットフォームを標準化している組織にとって、迅速な導入が可能で、別途ランタイムを運用する必要がないため、効率的な選択肢となり得ます。また、これは保護モデルがプラットフォームに依存することを意味します。購入を検討する際は、組織がそのプラットフォームから移行した場合に保護されたデータがどうなるか、また、そのプラットフォーム外にあるデータに対しても同じtokenization を適用できるかどうかを確認する必要があります。
特定のKMS、HSM 、またはクラウドと連携している
プラットフォームが特定のkey 管理システム、ハードウェアセキュリティモジュール、またはクラウドプロバイダーに依存している場合、tokenization の決定においてもその依存関係が引き継がれます。購入を検討する側は、keys のエクスポートが可能かどうか、別のkey 管理システムへの移行が可能かどうか、特定のアプライアンスが必要かどうか、そしてkey の管理権限を変更する必要が生じた場合にどうなるかを確認する必要があります。
「カップリング」をめぐる問題
私が購入しようとしているのは、データ保護のための管理機能なのか、それとも併せて購入するプラットフォーム、処理業者、あるいはkey 管理製品の機能の一部なのか。どちらも妥当な選択肢となり得ます。ただし、周囲の状況が変わった場合でも、その管理機能をそのまま引き継ぐことができるのは、そのうちの1つだけです。
Rixon プロバイダーに依存しないデータ保護レイヤーとして機能します。これは決済ゲートウェイやカードネットワークではなく、特定のクラウドやデータプラットフォームの導入を必要とせず、特定のkey 管理システムや専用ハードウェアも不要です。Rixon は決済分野で事業を展開しており、オーケストレーターやプラットフォームプロバイダーと連携して動作しますが、tokenization の制御機能自体は、これらいずれにも縛られることはありません。
すでに所有しているインフラストラクチャ内で動作するプラットフォームについてはどうでしょうか？
それはもっともな主張です。すでに運用しているプラットフォーム内でネイティブに動作するtokenization 機能であれば、迅速に導入でき、別途維持管理が必要なランタイムが追加されることもなく、チームがすでに使い慣れているガバナンスツールを利用できます。一方、専用エンジンは、導入・運用が必要なコンポーネントとなります。
ここでのトレードオフは、利便性に対する制御性と移植性です。専用エンジンを任意のリージョンや環境に配置することで、他の顧客との処理を完全に分離でき、データ保護に関する決定をプラットフォーム契約の将来性に左右されることもありません。すでに単一のプラットフォームに標準化されており、主権やマルチ環境の要件がない組織であれば、このトレードオフを異なる観点から合理的に検討することもあり得ます。重要なのは、このトレードオフを意図的に行うことです。
Tokenization およびコンプライアンス
Tokenization 機密データの存在や漏洩リスクを低減するのに役立ちます。ただし、これによって、法的、規制上、または業界の要件が自動的に満たされるわけではありません。
コンプライアンスの成果は、tokenization の導入方法、どのシステムが依然として原データを扱っているか、復元が許可されている場所、ポリシーを管理する主体、アクセス権の取り消し方法、復元試行のログ記録の有無、監査記録の保存方法、展開場所の管理方法、禁止されているデータ型の取り扱い方法、およびより広範なセキュリティ環境の管理方法によって左右されます。
適切に設計されたtokenization アーキテクチャは、データの最小化、最小権限の原則に基づくアクセス、利用目的の限定、地理的なアクセス制限、職務の分離、スコープ管理の取り組み、情報漏洩の影響軽減、管理されたデータ復旧、監査可能性、「プライバシー・バイ・デザイン」プログラム、およびデータ主権の要件を支援することができます。このアーキテクチャにより、データ所有者は、値がトークン化されたことだけでなく、誰がそれを復元したか、リクエストの発信元はどこか、どのポリシーによってそのアクションが許可または拒否されたかについても証明できるようになる必要があります。
保険契約の所有権は重要である
購入者は、token の構成、仮名化ルール、復元権限、地理的制限、管理ロール、監査アクセス、保存期間、取り消し、および展開場所を誰が管理するかを明確にする必要があります。顧客は、これらの管理機能を自社が所有するのか、それともプロバイダーが顧客に代わってそれらを定義・運用するのかを理解しておく必要があります。Tokenization は、 コンプライアンス対策 として最も有用です。
導入とデータ主権
tokenization がどこで実行されるかは、その仕組みと同じくらい重要になる場合があります。「Vaultless 」は、必ずしも「クラウド専用」を意味するわけではなく、また「顧客によるホスティング」を意味するわけでもありません。
マネージドSaaS
このプロバイダーは、tokenization 環境を運用し、APIs を通じて当該機能を提供しています。これにより、顧客の運用負担を軽減できますが、購入を検討する際には、サービスがどこで実行されるか、処理を特定のリージョンに限定できるか、元のデータが管轄区域をまたぐか、環境の管理主体は誰か、テナント間の分離がどのように実装されているか、およびどのようなサービスレベル保証が適用されるかについて評価する必要があります。
自分だけのクラウドを持ち込もう
tokenization エンジンは、プロバイダーが管理・サポートを行う一方で、お客様のクラウドテナント内で稼働します。これにより、環境をより細かく制御できると同時に、プラットフォームを独自に運用する負担を軽減することができます。
自己管理型ソフトウェア
顧客が、当該技術の導入、運用、パッチ適用、監視、および拡張を行います。これにより、直接的な制御力は高まりますが、インフラのセキュリティ、必要に応じてkey の管理、可用性、拡張、監視、パッチ管理、災害復旧、および管理者アクセス権など、より多くの責任が顧客に移転することになります。
オンプレミスでの導入
この技術は、顧客が管理するハードウェア上、またはプライベート環境内で動作します。これは、制限が厳格な、あるいは隔離されたユースケースでは必要となる場合がありますが、購入者は、その運用モデルが実用的であり、十分なサポートが受けられるかどうかを評価する必要があります。
適切な導入モデルは、組織の規制、運用、主権、およびセキュリティに関する要件によって異なります。
導入形態は中立的な選択肢ではありません。プラットフォームが「token 」ストアとリカバリ機能の分離に依存している場合、ランタイムを「tokens 」と同じ環境に移行すると、その分離が弱まり、通常はサポートおよびサービスモデルも同時に変更されます。購入者は、すべてのオプションが同等の保護を提供すると安易に想定するのではなく、各プロバイダーに対して、顧客がホストする形態やオンプレミスでの導入が、セキュリティ特性、分離モデル、およびサービス保証にどのような変化をもたらすのかを尋ねるべきです。
Vaultless 必ずしも移植性があるとは限らない
リバーシブルなtokenization システムは、いずれも継続的な依存関係を生み出します。問題は、依存関係が存在するかどうかではありません。問題は、その依存関係がどこに集中しているか、そして顧客がどの程度の制御権を保持しているかということです。
組織が数百万または数十億件のtokens を保存する場合、承認された際に元の値を復元するための信頼性の高い方法を確保しておく必要があります。
データの依存関係
購入者は、復旧機能を誰が管理しているか、移行期間中も顧客が業務を継続できるか、文書化された復旧tokenization プロセスが存在するかどうか、保護対象データを一括で移行できるか、新旧の環境を並行して稼働させることができるか、移行の処理能力とコストが明確に定義されているか、および契約終了後に監査記録がどのように扱われるかを確認する必要があります。
暗号に関する依存関係
keys や暗号関連資産が使用される場合、購入者は、keys の所有者が誰であるか、その保管場所、輸出が可能かどうか、別のkey 管理システムへの移行が可能かどうか、keys が紛失した場合はどうなるか、key の保管責任者が変更された場合はどうなるか、および顧客が特定のハードウェアセキュリティモジュールやクラウドサービスに縛られるかどうかを確認する必要があります。
業務上および商業上の依存関係
購入者は、ポリシー設定、管理者アクセス権、スケーリング、実行環境の配置、リージョンごとの展開、監査ログ、アップグレード、可用性、およびインシデント対応を誰が管理するかを明確にすべきである。契約書には、最低利用義務、利用量に応じた価格設定、解約手数料、移行支援、データ削除、設定のエクスポート、サービスの継続性、契約終了後のサポート、およびプロフェッショナル・サービスの要件について、明確に規定すべきである。
事業承継計画について確認すべき事項
移行および再tokenization のプロセスについて、文書化されたものはありますか？
既存のプラットフォームと置き換えられるプラットフォームは、並行して稼働させることができますか？
ポリシーや設定はエクスポートできますか？
監査記録は保存したり、エクスポートしたりできますか？
移行中は、サービスの継続性をどのように確保しているのでしょうか？
法的および運用上の観点から適切である場合、detokenization のバルク利用はサポートされていますか？
移行時に利用可能なスループットはどれくらいですか？
移住関連サービスは料金に含まれていますか、それとも別途料金がかかりますか？
ランタイムを顧客の環境に移行することは可能ですか？
契約終了後、プロバイダーが管理する設定やメタデータはどうなるのでしょうか？
データの削除手順は文書化されていますか？
退去時の義務は契約上定められていますか？
いかなるプロバイダーも、可逆的な「tokenization 」システムには依存性が生じないなどと主張すべきではありません。より望ましい目標は、不必要な依存性を減らし、変更のための文書化され、管理された道筋を提供することです。
Rixon のアプローチvaultless tokenization
Rixon は vaultless keyless アーキテクチャ を採用しており、これは顧客が保有するtokens と、それらを変換するために必要な機能を分離するように設計されています。
元のデータは一時的に変換され、権限のある要求者に返されます。元の値は利用可能な形式で保持されず、Rixon は「token 」と値との対応関係を一元的に保存することはありません。従来の暗号化手法keys は、token を導出したり復元したりするために使用されません。
Tokens 顧客環境内に保持されます。元の値を復元するには、対応するRixon エンジンに対して、有効かつ認証済みで、ポリシー評価済みのリクエストを送信する必要があります。これにより、2つの独立したセキュリティ境界が形成されます。つまり、顧客環境にはtokens が保持され、専用エンジンには変換機能が保持されます。顧客環境が侵害された場合、tokens が漏洩する可能性がありますが、それらを復元する方法は自動的に明らかになるわけではありません。一方、エンジンが侵害された場合でも、顧客のtoken の全保存データや、元の値が保持されたデータベースが自動的に提供されることはありません。
Rixon の各顧客は、専用のエンジンを通じて運用されます。1つのエンジンが複数の顧客のデータを処理することはないため、共有処理やテナント間の情報漏洩リスクが低減されます。すべての復元リクエストは、役割、地域、時間枠、ソースなど、データ所有者の有効なポリシーに基づいて評価されます。成功したリクエストと失敗したリクエストは個別にログに記録されるため、特定の機密値の復元を試みたユーザー、リクエストが発生した日時、発信元、および許可されたかどうかといった情報を把握することができます。
お客様は、token の構成およびセキュリティポリシーを所有・管理します。Rixon は、データ所有者のポリシーを適用するためのエンジンを提供します。このアーキテクチャでは、一元化されたtoken vault 、従来の暗号化key 管理、専用ハードウェア、あるいは特定の分析プラットフォームやデータプラットフォームの導入は不要です。
導入と、現実的なトレードオフ
マネージドSaaSおよび顧客によるクラウド展開が標準的な商用モデルであり、ハイブリッド型も利用可能です。いずれの場合も、このガイドの大部分の根拠となっている「tokens と変換機能が、それぞれ別々に管理される環境に配置されている」という特性は維持されます。
Rixon オンプレミスでの実行も可能ですが、これはデフォルトで提供されるものではなく、状況に応じてサポートされる形となっています。その理由は、商業的なものではなく、アーキテクチャ上のものです。ランタイムがtoken ストアと同じ環境内に配置されると、保護されたデータとそれを復元する手段との分離が弱まり、それに伴って運用モデルも変化します。これには、パッチ適用を行う主体、監視を行う主体、適用されるサービス保証の内容などが含まれます。 オンプレミスでの展開はケースバイケースで検討され、隔離や管轄上の要件がそのトレードオフを上回る状況に適しています。購入者は、Rixon を含むあらゆるプロバイダーに対し、展開方法を同等の選択肢のメニューとして扱うのではなく、顧客主導の展開によってセキュリティモデルにどのような変化が生じるかを尋ねるべきです。
Rixon tokenization rest における転送中のデータや、より広範なインフラストラクチャ全体にわたるデータの暗号化を補完するものです。これは暗号化に取って代わるものではありません。従来の形式保持暗号化（ ）への依存を回避しつつ、形式保持暗号化でしばしば対応されるユースケースをカバーするように設計されています。key
Rixon が主張していないこと
いかなる技術も、すべてのセキュリティリスクを排除できるわけではありません。「Rixon 」を導入したとしても、強固なIDおよびアクセス管理、通信時の暗号化、rest での暗号化、セキュアなソフトウェア開発、エンドポイント保護、クラウドセキュリティ、監視、最小権限の原則、職務分離、インシデント対応、データガバナンス、規制分析の必要性がなくなるわけではありません。
Rixon また、あらゆる形態の支払い詐欺を防止できるわけではなく、正当な手段で復元された機密データを、承認されたユーザーが不正に利用することを阻止することもできません。「Rixon 」は、顧客システム全体で保持される機密データの量を削減し、復元プロセスに対して管理され、監査可能なポリシーの境界を設けることを目的としています。
アーキテクチャの変化に伴い、攻撃者が狙うべき対象も変化します。重要な標的としては、API の認証情報、ワークロードのID、ポリシー管理、承認済みアプリケーション、およびtokenization 前または復旧後の実データなどが挙げられます。これらの制御措置は、顧客のより広範なセキュリティプログラムの一環として管理される必要があります。
購入者の評価チェックリスト
技術審査、調達、およびベンダーとの協議の際には、これらの質問を活用してください。Rixon を含め、すべてのプロバイダーに対して同じ質問リストを提示してください。
建築
- このプラットフォームはvaultless ですか？
- これもkeyless なのでしょうか？
- フォーマット保持型暗号化を採用していますか？
- それはKMSかHSM かによって異なりますか？
- tokens はオフラインで元に戻すことはできますか？
- 元のデータはどこかに保存されていますか？
- token のマッピングは保存されますか？
- vault の後継機種は何ですか？
- token は、プレフィックスやサフィックスなど、元の値の一部を平文で保持していますか？
- tokens は決定論的ですか？また、データ要素ごとに設定することは可能ですか？
- このプラットフォームでは、ラテン文字以外の文字や複数の文字セットが混在するフィールドをトークン化できますか？
- 導入には、データベースのスキーマやフィールド定義の変更が必要ですか？
セキュリティ
- 攻撃者がデータを復元するには、何を侵害しなければならないか？
- tokens は、リカバリ機能とは切り離されているのでしょうか？
- ポリシーはリクエストごとに評価されるのでしょうか？
- ログインすると、常時有効な復旧アクセス権が作成されますか？
- アクセス権は直ちに取り消すことができますか？
- 失敗したリクエストはログに記録されますか？
- 処理はシングルテナント方式ですか、それとも共有方式ですか？
- 管理権限の侵害による影響範囲はどの程度か？
- プロバイダーの社員は、翻訳を行うランタイムにアクセスできますか？
- ランタイムは不変ですか？また、侵害の疑いがある場合、ランタイムにはどのような処理が行われるのでしょうか？
結合と独立性
- tokenization は、決済ゲートウェイ、決済処理業者、またはカードネットワークと連携していますか？
- 処理関係が変更された場合でも、tokens は引き続き使用可能ですか？
- このプラットフォームは、特定のデータプラットフォームやレイクハウスに固有のものですか？
- tokenization は、そのプラットフォーム外のデータにも適用できますか？
- このプラットフォームは、特定のクラウド、KMS、HSM 、あるいは専用ハードウェアに依存していますか？
- これはデータ保護のための対策なのでしょうか、それとも購入する他の製品の機能なのでしょうか？
コンプライアンス
- 保険契約の所有者は誰ですか？
- 回復は、地理的要因、時間、役割、および原因によって制限されることはあるのでしょうか？
- 個々の復旧事象は監査の対象となるのでしょうか？
- ログを顧客のSIEMにストリーミングすることは可能ですか？
- アーキテクチャは、データの最小化を支援することができるでしょうか？
- デプロイはリージョンに制限されることがありますか？
- データの保持と削除はどのように処理されるのでしょうか？
導入
- SaaSは利用可能ですか？
- このプラットフォームは、顧客のクラウド環境で動作しますか？
- オンプレミスでの導入はサポートされていますか？
- この環境の運用やパッチ適用は誰が担当しているのですか？
- このプラットフォームでは、特定のクラウドやデータプラットフォームが必要ですか？
- 1つのプラットフォームで、毎晩のバッチ処理とリアルタイムのトランザクション処理の両方に対応することは可能でしょうか？
- 顧客によるホスティングまたはオンプレミスでの導入の場合、セキュリティモデルやサービスに関する約束事項にはどのような変化が生じますか？
- レジリエンスと災害復旧はどのように管理されているのでしょうか？
移植性
- 設定をエクスポートすることはできますか？
- re-tokenization の動作は文書化されていますか？
- 移行中にプラットフォームを並行して実行することは可能ですか？
- 移行期間中はどのようなサポートが受けられますか？また、移行費用は明確に定められていますか？
- 監査ログは保存できますか？
- 顧客は、独自のハードウェア、KMS、または分析インフラに縛られているのでしょうか？
よくある質問
Vaultless tokenization tokenization は、元の機密値とその との関連性を保存するために、一元化されたデータベースを使用しません。このプラットフォームは、保存されたマッピングを参照する代わりに、別の方法を用いて値を に変換し、権限が与えられている場合にはその値を復元します。 には、プラットフォームが何を削除したかが記載されていますが、何がそれに置き換えられたかについては記載されていません。token token Vaultless
いいえ。Vaultless とkeyless は同じものではありません。プラットフォームは、token vault を削除しつつも、暗号化keys や保護された暗号化素材に依存して、tokens を生成または復元することができます。こうしたアーキテクチャにおいて、セキュリティはkey の保管、key 管理システム、ローテーション、バックアップ、および特権アクセスに依存しています。keyless のアプローチでは、保護された値を導出または復元するために、従来の暗号化key に依存することを回避します。
Vaultless の各プラットフォームは、tokens の作成方法、復旧を可能にする仕組み、暗号化されたkeys が必要かどうか、変換が行われる場所、顧客の分離方法、ポリシーの管理主体、製品が他のプラットフォームと連携しているかどうか、および組織がプロバイダーをどの程度容易に変更できるかという点において、大きく異なります。
はい。一部のvaultless プラットフォームでは、元のデータの形式を維持した値を生成するために、形式保持暗号化（format-preserving encryption）を採用しています。これらのシステムも依然として、暗号技術（keys ）および暗号管理インフラ（key ）に依存しており、その設計における「暗号化」（detokenization ）は復号操作となります。Rixon は、同社の「暗号化」（tokens ）を形式保持型とは説明していません。同社は、key に基づく暗号文を表現することなく、既存のスキーマに適合するように設計された「形式互換型」（format-compatible）の暗号化（tokens ）を採用しています。
これはアーキテクチャによって異なります。復旧が暗号化された「key 」に依存する場合、token ストアとkey マテリアルの両方を入手した攻撃者は、プロバイダーの管理の及ばない範囲で復元を行う手段を得る可能性があります。一方、復旧に、独立した認証を経て有効なポリシーに基づいて評価されるリアルタイムのリクエストが必要な場合、盗まれたtoken ストアだけでは、そのような手段は得られません。購入者は、各プロバイダーにこの点を直接確認する必要があります。
これは設計によって異なります。一部のプラットフォームでは、token 内に元の値の一部（例えば、支払いカードの先頭桁や末尾4桁など）を意図的に保持しています。これらは、issuer 、商品タイプ、そして多くの場合、国を特定することができます。これとは別に、決定論的なtoken は等価性を保持するため、値の選択肢が少ないフィールドに対するtokens の列は、個々のtoken を復元できない場合でも、頻度分析をサポートすることができます。 購入者は、token 内に平文の断片が含まれているかどうか、およびデータ要素ごとに決定性を設定できるかどうかを確認する必要があります。
一般的に言えば、どちらも正しいとは言えません。決定論的なtokens は、同じ入力に対して毎回同じ結果となるため、システム間で結合が可能であり、照合、重複排除、分析に利用できます。また、等価性が保たれることも意味します。一方、ランダム化されたtokens は、その「漏洩」を排除しますが、それとともに結合可能性も失われます。重要な点は、プラットフォームが、すべてのフィールドに一律の設定を適用するのではなく、データ所有者がデータ要素ごとに選択できるようにしているかどうかです。
いいえ。リバーシブルなtokenization システムはすべて、保護された値を復元するために使用される機能に対して何らかの依存関係を生み出します。重要なのは、その依存関係がどこに集中しているかという点です。購入者は、それが独自のvault 、暗号化keys 、特定のクラウド、データプラットフォーム、決済処理の提携関係、あるいは管理型翻訳サービスのいずれに結びついているかを評価し、導入前に文書化された移行および撤退プロセスを要求すべきです。
その可能性はあります。「Tokenization 」は、決済ゲートウェイや決済処理サービスの一機能として、データプラットフォームやレイクハウスのネイティブ機能として、あるいは特定のkey 管理システムやハードウェアセキュリティモジュールに紐付いた機能として提供されることがあります。組織がすでにそのプラットフォームを標準化している場合、いずれの結合形態も妥当な選択肢となり得ますが、いずれも将来の選択肢を狭めることになるため、当然のことと決めつけるのではなく、明確に評価する必要があります。
はい。「Tokenization 」は、データ最小化、適用範囲の管理、最小権限の原則、管理された復旧、地理的制限、および監査可能性の実現を支援します。ただし、これだけで規制や規格への準拠が自動的に満たされるわけではありません。コンプライアンスの達成度は、組織による導入状況および組織全体の統制環境によって左右されます。
Tokenization は、暗号化を補完するものです。組織は、転送中のデータ、rest 上のデータ、バックアップ、通信、およびインフラストラクチャに対して、引き続き適切な暗号化を適用する必要があります。
専用の処理環境を構築することで、共有ランタイムやテナント間の相互影響を低減し、1つのエンジンが侵害された場合の影響を限定することができます。ただし、シングルテナント環境であるからといって、強力なアイデンティティ管理、監視、アプリケーションセキュリティ、およびクラウド管理の必要性がなくなるわけではありません。
復旧を可能にする要素は何か、また攻撃者が元のデータを入手するために何を侵害する必要があるのかを問うてみてください。もしvault が存在しない場合、何かがそれに取って代わっていることになります。このたった一つの質問への答えは、「vaultless 」という言葉そのものよりも、そのプラットフォームについて多くのことを明らかにしてくれます。
Vaultless これは出発点であり、完全なセキュリティアーキテクチャではない
token （vault ）を廃止することで、重大な集中リスクを軽減できます。ただし、購入者は、それに代わって何が導入されたかを理解しておく必要があります。セキュリティとコンプライアンスの成果は、tokens がどのように作成されるか、復旧を可能にする要素は何か、keys が関与しているかどうか、tokens がオフラインで攻撃を受ける可能性があるかどうか、変換がどこで行われるか、テナントがどのように分離されているか、ポリシーを誰が管理するか、各復旧リクエストがどのように評価されるか、その制御が他の製品と連動しているかどうか、プラットフォームがどこに展開可能か、そして顧客がどのようにしてそのサービスから移行できるか、といった点に左右されます。
「vault 」が存在しないことは重要です。完全な信頼モデルこそが、セキュリティ、コンプライアンス、運用、および移植性における実際の成果を決定づけるものです。
vaultless tokenization のアーキテクチャの評価について？
このフレームワークは、技術レビュー、調達、およびベンダーとの協議の際に活用してください。『Rixon 』は、セキュリティチームや技術チームが、機密データがどこに存在するか、どのように変換すべきか、どこで復旧を行うべきか、そしてどのポリシーでアクセスを管理すべきかを評価する上で役立ちます。
組織は、採用する技術アーキテクチャにかかわらず、適用される規制要件を遵守する責任を負います。本ガイドは、「tokenization 」市場における一般的なパターンについて説明するものであり、特定のベンダーに関する見解を示すものではありません。購入を検討される方は、評価対象となる各プロバイダーに直接連絡し、アーキテクチャの詳細についてすべて確認してください。