トークン化 vs. 暗号化：適切なデータ保護アプローチの選び方

暗号化とトークン化はいずれも機密データを保護し、コンプライアンスを支援し、あらゆる主要なセキュリティフレームワークに登場します。ですが、両者は本質的にまったく異なる仕組みで動作します。特定のユースケースに対して誤ったアプローチを選ぶと、コンプライアンス範囲の縮小という効果を見送ってしまう、あるいは不要なアーキテクチャの複雑さを導入してしまう可能性があります。

セキュリティチームがこの判断に苦労するのは、両方の技術が目的面で重なっているためです。どちらも機密データを、未承認の第三者に対して読み取れない状態にします。どちらも規制要件を満たすのに役立ちます。

ただし、機密データが保存される場所、データをどのように復元できるか、そしてどのシステムがコンプライアンスの対象範囲に残るのかは異なります。これらの違いは、監査の負担、インフラ設計、そしてリスク・ポスチャに直接影響します。

適切なアプローチは、アイデンティティが（人間と non-human）どのようにデータにアクセスするのか、データがどこにあるのか、そしてサイバー回復力を高めるために、また全体としてのデータセキュリティのポスチャを改善するために、実際にどのリスクを低減しているのかによって決まります。

トークン化 vs. 暗号化：基本

この2つのアプローチを並べて比較する前に、それぞれが単独でどのように機能するのかを理解することが重要です。

以下のセクションでは、暗号化とトークン化を定義し、それぞれの中核となる仕組みを概説し、目標が重なる部分と異なる部分を明確にします。

トークン化（Tokenization）とは？

トークン化（Tokenization）では、機密データをランダムなトークン、または形式を保持するトークンに置き換えます。元のデータは、別の強固なトークン保管庫（token vault）に保存されます。16桁のカード番号は、保管庫とその対応表（マッピング）にアクセスできない限り、実在するように見えても完全に無意味な別の16桁の値に変わります。

PCI tokenization guidelines では、3 つのトークン生成アプローチが定義されています：

• 数学的に可逆な暗号化関数
• 一方向で元に戻せない暗号化関数（ハッシュベース）
• トークンが元のデータと数学的に一切関係しないインデックスまたはランダムな割り当て

この最後の区分こそが、トークン化に独特のセキュリティ特性を与えます。ランダムな割り当てで作成されたトークンが運用システムで露出したとしても、基になる値は明らかになりません。

トークンを元のデータに戻すための逆変換アルゴリズムもなく、復号鍵もありません。実データに戻る唯一の道は、金庫（vault）そのものを経由することです。

暗号化とは何ですか？

暗号化は可逆的な変換であり、暗号アルゴリズムと鍵を使って平文を読めない暗号文（ciphertext）に変換します。正しい復号鍵を渡せば、元のデータが返ってきます。

実際には、暗号化はあらゆる層で用いられます。フルディスク、データベース（TDE）、フィールド単位、アプリケーション単位、そして転送中（TLS）です。

重要な依存要素は鍵管理です。暗号化鍵は、事前有効化、稼働中の使用、無効化、侵害（漏えい）対応、そして破棄というライフサイクルをたどります。各段階では、鍵の生成、配布、ローテーション、安全な保管に関する運用上の要件が必ず発生します。

トークン化と暗号化の主な違い

どちらの手法も、機密データを保護し、インシデントの影響を低減し、規制への準拠を支援することを目的としています。しかし、いくつかの重要な点で違いがあります。

• 可逆性：暗号化は、正しい鍵があれば常に可逆です。トークン化は、保管庫（vault）へのアクセス権を持つシステムでのみ可逆であり、また一部のトークンの種類（ワンウェイのハッシュベース）については、そもそも可逆ではありません。
• データ形式：標準の暗号化では、形式保持暗号化（format-preserving encryption（FPE））を使用しない限り、データ形式が完全に変わる可能性があります。トークン化は通常、元の形式を維持するため、16 桁のカード番号は 16 桁のままです。
• コンプライアンスの範囲： 暗号化されたデータは PCI DSS のようなフレームワークの範囲に引き続き含まれ、鍵にアクセスできるすべてのシステムも範囲に残ります。トークンデータ環境（token data environment）外に保存されたトークンは、PCI の範囲から外れる可能性があり、その結果、監査の負担を大幅に軽減できる場合があります。
• パフォーマンス： 暗号化は、外部依存関係なしで、予測可能な計算オーバーヘッドを追加します。ボルトベースのトークン化では、往復のボルト参照（round-trip vault lookups）によりレイテンシが発生します。ボルトレスのアプローチでは、範囲のメリットを速度と引き換えます。
• 鍵管理： 暗号化では、すべての復号ポイントでライフサイクル全体にわたる鍵管理が必要です。トークン化では、その負担をボルトに集中させ、運用上の責任をボルト提供者に移します。
• 向いているケース： 暗号化は、転送中のデータ、非構造化データ、そして頻繁にアクセスされるレコードに対して最も効果的です。トークン化は、構造化されたフィールド（PAN、SSN）、ストレージ中心のデータ、ならびにコンプライアンスの範囲を削減する目的に最適です。

根本的なアーキテクチャ上の違いは、暗号化では元のデータが環境内に保持されたまま、正しいキーがなければ読めない状態になる点です。これによりデータは広く利用できる一方で、これらのキーが存在するあらゆる場所で強固なキーマネジメントが必要になります。

一方で、トークン化は機密データを業務（運用）システムから完全に取り除き、単一の強化された金庫（vault）に集中させることで、原本データが存在する場所を最小限に抑えます。ただし、最も重要なインフラとなる金庫への依存が追加されます。

トークン化を使用するべきタイミング

トークン化は、機密データを保存または参照する必要がある一方で、原本の形式で処理されることがほとんどない場合に、最大の価値を提供します。以下のセクションでは、トークン化の理想的なユースケースと、効果的に導入するための実践的な考慮事項を取り上げます。

トークン化に最適なシナリオ

トークン化が最も適しているのは、次の3つの領域です：

• 決済カードデータおよび国民識別子： PAN、SSN、政府発行のID、および同様の構造化された値で、アプリケーションがそのデータを参照として利用する一方で、完全な機密値が必要になることはめったにないケースです。システムが主に口座番号を保存して受け渡すだけで、実際には処理していない場合は、トークン化の対象になり得ます。
• SaaSおよびマイクロサービス環境における顧客識別子： 複数のサービスが顧客データを扱うアーキテクチャでは、入口で識別子をトークン化し、下流にはトークンのみを渡すことで効果が得られます。実在のPIIに触れるシステムが少ないほど、コンプライアンスの範囲（コンプライアンス負荷）は小さくなります。
• コンプライアンス範囲の縮小： PCI DSS や同様のフレームワーク要件の対象となるシステム数を減らすことが優先事項であるような環境であれば、どこでも当てはまります。運用データベースやアプリケーション層で機密値をトークンに置き換えることで、次回のアセスメント範囲を大幅に縮小できる可能性があります。

これらのシナリオでは、トークン化によって、一貫したデータセキュリティの態勢を維持しながら、データ保護とコンプライアンス効率の最良のバランスを実現できます。

暗号化を使用すべきとき

暗号化は万能のコントロールではありませんが、明確に必須、または強く推奨される選択肢となるシナリオがあります。以下のセクションでは、暗号化が最も適している領域と、現代の環境によって組織が暗号化を展開・管理する方法がどのように変わったのかを概説します。

暗号化に最適なシナリオ

暗号化は、次の4つの領域において必須、または強く推奨されるコントロールです。

• 転送中のデータ： トークナイゼーションは個々のデータ要素を保護しますが、通信チャネルそのものは保護しません。ここでの基本となる対策は TLS とトランスポート層の暗号化であり、トークナイゼーション戦略でこれらを置き換えることはできません。
• 非構造化データ： 書類、画像、通信、および大きなテキスト項目は、トークナイゼーションの構造化データモデルにきれいに当てはまりません。暗号化は、ファイル、ディスク、またはアプリケーション層で自然に対応します。
• 頻繁にアクセスされるデータ： 多くのシステムが、運用や分析のためにデータを原本の形で処理する必要がある場合、暗号化によって vault への往復（ラウンドトリップ）なしに、環境全体でデータを利用可能な状態に保てます。
• バックアップとアーカイブ： 暗号化されたバックアップで、キーを別々に保管しておけば、データのライフサイクル全体にわたって保護を継続できます。重要なルール：暗号化キーを、それが保護するデータと一緒に保存してはなりません。

これらのシナリオでは、暗号化が一般的に「使いやすさ」と「セキュリティ態勢の測定可能な改善」のバランスが最も良くなります。

トークン化と暗号化を組み合わせる

多くの環境では、最も強力なアーキテクチャは単一の技術だけに依存しません。トークン化と暗号化は異なるリスク要因に対応しており、戦略的に組み合わせることで、冗長な複雑さを加えることなく多層的な防御を実現できます。

なぜ2つの技術を重ねて使うのか

それぞれの技術には、もう一方が埋めるギャップがあります:

• 暗号化は、転送中のデータを保護し、非構造化コンテンツを安全に保ちますが、運用システムから機密データを削除したり、コンプライアンスの対象範囲を縮小したりはしません。
• トークン化は、アプリケーション層から機密値を取り除き、コンプライアンス上の負担を縮小しますが、これらのシステムが依存する通信チャネルや、元のデータが保存されている金庫（vault）自体は保護しません。

2つを重ねることで、トークン化だけではカバーできない領域（通信中、非構造化データ、金庫(vault)そのもの）を暗号化し、暗号化だけでは範囲から外せない領域（運用データベースに保存された静止状態の構造化された機密フィールド）をトークン化できます。

各層は、異なるデータ状態またはセキュリティ領域に対応する必要があります。同じシステムで同じデータに対して、異なる目的に役立つことなく両方の制御を適用してしまうと、保護が増えることはないのに複雑さだけが増えます。

実際にどのように機能するか

典型的な階層型アーキテクチャは、次の流れに従います：

1. 取り込み: Web アプリケーションがカードデータを受信すると、HTTPS 経由の API 呼び出しによって PAN をトークン・ボールト（token vault）へ直ちに送信します。通信チャネルは暗号化されており、データ要素はまさにトークン化されようとしています。
2. 保管: ボールトは元の PAN を保存します（ボールト内で保管時暗号化）。そしてアプリケーションにトークンを返します。アプリケーションはデータベースにトークンだけを保存し、そのデータベースは PCI DSS のスコープ外に置かれます。
3. 処理: アプリケーションが支払いを処理する必要がある場合、トークンをボールトに送り返します。ボールトは元の PAN を取得し、暗号化されたチャネルを通じてそれを決済処理業者（payment processor）へ転送します。
4. スコープの封じ込め: カード会員データ環境（cardholder data environment）に残るのは、ボールトとその直接接続されたコンポーネントのみです。その他のシステムは、原本の機密データではなく、トークンまたは暗号化された転送のみを扱います。

このパターンはエンドツーエンドの保護を実現します。暗号化により、転送中のデータと保管中のボールト内の内容が保護され、トークン化によって機密値が運用システムの外に保たれ、コンプライアンスのスコープが最小化されます。

ユースケースに合った適切なアプローチを選ぶ

各技術がどのように機能し、どこに適しているかを明確に理解したうえで、次のステップはそれらの機能をお客様の具体的な環境に照らし合わせてマッピングすることです。以下のセクションでは、そのプロセスを導くための評価基準と意思決定パターンを示します。

評価基準

核心となる問いは明確です。このデータは処理のために元の形式に復元する必要があるのか、それとも主に保存されて参照されるだけなのか、という点です。

下流の処理（後続処理）で頻繁に使用されるデータは暗号化を示唆し、保護された状態からほとんど出ることのないデータはトークン化を示唆します。

その出発点を過ぎると、意思決定を左右する5つの実用的な基準があります。:

• データの種類と形式: 構造化フィールド（PAN、SSN）はトークン化の自然な候補です。非構造化コンテンツ（ドキュメント、画像、自由記述のテキストフィールド）には暗号化が必要です。
• アクセス頻度とパターン: 多くのシステムが元の形式のまま処理する必要があるデータは、vault への往復（ラウンドトリップ）を回避できるため、暗号化が適しています。保存され、参照として渡されるデータは、トークン化が適しています。
• パフォーマンス上の制約: 高スループットかつ低レイテンシーのワークロードでは、vault のルックアップに耐えられない可能性があります。暗号化の性能は主に自分自身の処理能力とローカル I/O によって決まり、通常は外部の vault やサービスへの往復（ラウンドトリップ）を必要としません。
• 規制上の要因: PCI DSS のスコープを減らすことが優先事項であれば、トークン化は暗号化では実現できない道を提供します。HIPAA が主要なフレームワークである場合、トークン化はセキュリティを向上させますが、スコープは削減しません。
• サードパーティ連携の要件：特定のデータ形式を想定しているレガシーシステムでは、形式を保持するトークン（format-preserving tokens）が有効な場合があります。分析や運用のために生の値を処理する必要があるシステムでは、暗号化が必要です。

これらの基準をアイデンティティのフローに結び付け直してください。どの人間のユーザー、アプリケーション、サービスがデータに触れるのか、そして データライフサイクル は、取り込み（ingestion）からアーカイブ（archival）までの間でどのような姿になるのかを考えます。

判断パターン

これらのパターンは、ほとんどの環境でうまく機能します：

• トークン化（tokenization）を使用する ほとんどの場合にデータを参照するだけで、コンプライアンスのスコープを縮小したいときに有効です。運用システムが保管しているものの、元の形式のまま処理することがほとんどない PAN、SSN、医療記録番号などが対象です。
• 暗号化を使用してください 多数のシステムが、運用、分析、または通信のために生データを処理する必要がある場合に。ドキュメント、トランザクションログ、転送中のデータ、そしてあらゆる非構造化データ。
• 両方を使用してください 高リスク、または規制対象のワークロードでは特に有効です。保存時は、構造化された機密フィールドをトークン化します。転送中のすべてを暗号化します。トークン・ボールト（token vault）を暗号化してください。保護はデータの状態ごとに重ね、冗長に重複させないようにします。

これらを一貫して適用することで、サイバー耐性と監査対応の準備を強化しながら、運用の複雑さを減らせます。

Netwrix はどのように組織の機密データを保護するのか

トークン化と暗号化のどちらを選ぶかは、多くの組織が自信を持って答えられない質問への回答を求めます：

• 機密データは実際にどこに保存されていますか？
• 把握できていなかった PAN や SSN を保持しているのは、どのシステムですか？
• 誰がアクセスしていて、そのアクセスは今も正当化されていますか？
• ファイルに何が保存されていて、それらはどこで使用されていますか？

The Netwrix 1Secure Platform は、その基盤となる可視性から始まり、ファイル システム、データベース、SharePoint や Teams のようなコラボレーション プラットフォーム全体で自動的な検出と分類を提供します。これだけでも、保護戦略を大きく見直すことができます。ID は、誰がどの条件で機密データにアクセスできるかを決定するため、トークン化または暗号化を効果的に適用するには、ID と権限の可視性が不可欠です。

そこから、プラットフォームは暗号化やトークン化では対応できないガバナンス層に取り組みます。つまり、認可されたユーザーがアクセスした後に何が起こるのかです。

ネストされたグループのメンバーシップ全体における実効権限を算出し、データ所有者を特定し、キー管理インフラやトークン・ボールトにアクセスできる形骸化した特権アカウントを可視化し、アクセスの異常を監視します。

PCI DSS、HIPAA、NIST の各フレームワークに対する継続的なコンプライアンス報告により、定期的な監査の慌ただしい準備を、必要なときに即座に取得できる証拠へ置き換えます。

Netwrix demo をリクエストして、1Secure Platformがハイブリッド環境全体でデータ保護戦略をどのように支援するかをご確認ください。