0 まえがき
技術革新が世界を席巻するデジタル化の波をリードする中、データは企業発展の生産の中核要素となっています。Google や Facebook などのハイテク企業は、無料で優れたソフトウェアとサービスを提供し、多数のユーザーにアクセスし、データ リソースを活用することで、大きな商業的成功を収めています。しかし、急速な発展と同時に、企業はデータガバナンスを無視し、多数のデータ漏洩、アルゴリズム悪用、プライバシー関連の問題を引き起こしています。Facebookの「ケンブリッジ・アナリティカ」スキャンダルや2020年の米国選挙などの画期的な出来事とともに、この危機は最高潮に達している。データ セキュリティとプライバシーに関する懸念に基づいて、欧州連合の GDPR は最新のプライバシー コンプライアンスの導入を主導し、その後世界を席巻し、もう一つの不可逆的な傾向となりました。
企業が進むべき道は 2 つあります。1 つはデータ テクノロジーの革新を通じて存続と発展を確保することであり、もう 1 つはユーザー データのセキュリティを確保することです。この 2 つの道の選択とバランスの中で、倒産する企業もあれば、生き残って新たな活力を発揮する企業もあります。
私たちの考え方を変え、革新に勇敢になることによってのみ、危機を機会に変え、長期的な発展を達成できることがわかります。私たちは転換傾向を認識する必要があります。それは、デジタル時代の前半における大規模で非効率的で洪水集中的な炭素増加から、効率的なデータ管理とガバナンス機能に基づく高品質で高効率のデータカーボンニュートラルへの移行です。この変革の中で生き残って目立つためには、技術革新が重要な出発点であり、重要な点は次の 2 つの核となるアイデアを把握することです。
- 強力なデータ アプリケーションの生産性特性を認識し、積極的に技術変革を実行し、高度なデータ管理技術を駆使して、データ利用効率とガバナンス レベルを向上させる必要があります。
- プライバシーコンプライアンスの目的と本質を深く研究して理解し、「可用性、不可視性」という中心的な考え方に従い、効率性とガバナンスの統合を達成します。
1. セキュリティに対するデータテクノロジーの課題
デジタル アプリケーション環境では、データには次の特性があります。
- データのモビリティとオープン性: デジタル経済学の理論によれば、データが商業的価値を生み出すには、低コスト、大規模な供給、効率的なフローが必要です。従来のネットワーク セキュリティが最小限に抑えられ、層ごとに承認され、層ごとに強化されると、データ生成の活力は大幅に制限されます。さらに、データが流れるすべてのノードで高度な保護ベースラインを満たすためのコストは、組織の手が届く範囲を超えています。
- データの再現性と制御の喪失: データは流動的な資産であり、一度アクセスされるとその制御は移転され、プロバイダーはデータに対する制御を失います。データ アプリケーションでは従来の信頼境界がますます曖昧になってきているため、新しいデータ アーキテクチャの下で一元化されたセキュリティ ポリシーを実装するのはコストがかかり、効果もほとんどありません。
- 変わりやすいデータ形式と複雑なアプリケーション: データはほぼすべての IT システムで送信、保存、処理されますが、その複雑さは想像を超えています。AI、機械学習、さまざまな革新的なデータ アプリケーションと組み合わせると、データ使用のロジックを理解することがさらに難しくなり、データの全体像を理解することはほとんど不可能になります。
- データの脅威は複雑で常に変化しています。データの膨大な商業的価値は、黒人や灰色の産業チェーン、社内外の人材、さらには商業スパイや国際スパイさえも引き寄せます。攻撃手法や動機は無限に現れ、防御することは不可能になります。
図1 従来システムは集中保護モードでデータ漏洩
従来のモードでは、データはクリア テキストでシステム内を循環し、データの露出は膨大になります。攻撃者は、アプリケーション、ストレージ、ホスト システムの入り口、システムを攻撃するための承認されたアカウントなど、さまざまなチャネルを通じて大量のデータを取得します。
図 2 従来モードでの水平データ露光
デジタル シナリオでは、データは数万のアプリケーションやタスク間で転送されます。各アプリケーションには独自のロジックがあり、すべてのアプリケーションを準拠させるには膨大なコストがかかります。このような広範かつ複雑な環境でデータ セキュリティを保護するために、従来のシステム中心の防御モデルを採用すると、防御戦線が長すぎて、強いものを攻撃し、弱いものを守るというパターンにより、データ セキュリティ ガバナンスが長期にわたることになります。不利益。考え方を変え、データサービスが急速に拡大する環境においては、セキュリティ保護能力も高まるデータ中心のセキュリティ防御革新機構を構築する必要がある。
2. トークン化 - デジタル世界の銀行システム
トークン化スキームは、現実世界の銀行システムを指します。銀行システムが出現する以前、市場における経済活動は主に現金取引でした。現金の過度な露出により、窃盗や強盗事件が多発し、護衛業は人気があるものの、雇えるのは一部の富裕層のみであり、多額の社会資産が失われている。銀行システムは時代の要請に応じて登場しました。利用者は現金を入手したら、すぐに銀行に行って現金を預金（同等の代替品）に交換し、この代替品である電子現金が社会全体に流通しますが、非常に限られた時間内でしか交換できません。まれなシナリオを現金に変換します。銀行システムの普及とさまざまなオンライン決済アプリケーションの人気により、このような現金の使用シナリオはますます少なくなってきています。お金を強奪したい場合は銀行に行くしかありませんが、銀行は厳重に警備されています。
同様に、個人の機密データ (PII) が最初に組織のビジネス システムに入ったときに、コア資産としてのデータを使用して、平文データ (P) を 1 対 1 に対応する仮名トークンに置き換えることができます。その後の組織全体のアプリケーション環境において、トークンは効率的に循環されます。トークンと平文の間には 1 対 1 の対応関係があるため、ライフサイクルのほとんどのシナリオで送信、交換、保管、使用のために平文を置き換えることができます。また、トークンは安全で信頼性の高いトークン化サービスを通じてのみ平文に変換できます。ハッカーや内部または外部の悪意のある攻撃者は、たとえそれを入手したとしても役に立ちません（目に見えません）。Token 独自のセキュリティ属性により、主要なデータ ソースとデータ ハブが組織内で管理されている限り、Token のみが流通に使用されます。デフォルトでデータ セキュリティを実現するには、新しい平文データを積極的にトークンに置き換える必要があります。これにより、個人の機密データのガバナンス問題が根本的に解決されます。
図 3 トークン化されたデータの公開
上の図3に示すように、トークン化を推進することで、実際に平文にアクセスできるサービスを2桁に圧縮し、データサービスの露出を1%未満に減らすことができます。
図 4 トークン化後のデータの長期的公開
上の図 4 に示すように、トークン変換後、機密データにはストレージが 0、キャッシュが 0、インターフェイスが 0、データ ウェアハウスが 0 あります。平文データへのアクセスを取得できるのは、復号化権限のある少量のホスト メモリと UI だけです。UI は、その後のきめ細かいアクセス制御と監査リスク制御手段を通じてリスク制御を実装します。少量のメモリ データの場合は、量が限られているため、特定の強化およびリスク管理手段を使用して強化できます。包括的なトークン化が実現すれば、機密データの全体的なリスク管理能力も大幅に強化できます。
3. トークン化ソリューションの導入
3.1 トークン化とは何ですか
トークン化は、個人の機密データを非機密データと同等の代替品であるトークンに置き換え、ビジネス システム内で循環させることでデータ リスクを軽減し、プライバシー コンプライアンスを満たすソリューションです。トークン化は、匿名化テクノロジーの一種です。これは、銀行カード (PAN) を置き換えるためにペイメント カード業界 (PCI) シナリオで最初に登場しましたが、一般的なデジタル シナリオでは個人機密情報 (PII) を置き換える傾向があります。
- 個人固有の識別情報 (PII) : ID カード、携帯電話番号、銀行カード、電子メール、WeChat アカウントまたは住所など、特定の自然人に直接的または間接的に関連付けることができる固有の識別情報。PII 情報のみに依存し、他の公開情報と組み合わせることで、自然人を見つけることができます。PII 情報が漏洩すると、なりすましや詐欺など、個人の生命や財産に損害を与える可能性があります。したがって、国内外のさまざまな法律や規制は、企業に PII のライフサイクル全体を保護することを明確に要求しています。
- 匿名化 (匿名化) : 特定の技術的手段を通じて、機密データが置換または変換され、個人の機密データと自然人との関連性が一時的または永久に排除されます。具体的な手段としては、仮名化、匿名化、データ暗号化などが挙げられます。
- 仮名化: 機密データを人工的な ID または仮名に置き換えることにより、誰も許可なく仮名を使用して元の自然人との関係を確立できなくなります。トークン化は仮名化の実装メカニズムであり、広い意味では、この 2 つの概念は置き換えることができます。仮名化は、GDPR を含む認知された匿名化スキームです。仮名化と PII の間には 1 対 1 の対応関係があり、特定のシナリオでは元のデータを復元できることに注意してください。
- 匿名化: 機密データの一部またはすべてをカバーまたは置き換えて、元のデータまたは自然人との関係を完全に失うこと。匿名化は元に戻すことができず、一般的に使用される匿名化手法にはデータ マスキングが含まれます。
- データ暗号化: 国家機密対称アルゴリズム SM4 や共通暗号化アルゴリズム AES などのデータ暗号化アルゴリズムを使用して、機密データを暗号化し、暗号文 (Cipher) を生成します。これは、キー管理システム (KMS) の暗号化キー認証がなければ実行できません。を取得します。復号化して平文を取得します。仮名化されたトークンとは異なり、暗号文は直接使用属性がなく、平文を復号化した後にのみ使用できることに注意してください。したがって、暗号文は保存と情報送信にのみ使用でき、検索、関連付け、クエリ、マッチングなどのデータ分析シナリオなどの使用範囲が大幅に制限されます。
3.2 トークン化の基本設計
3.2.1 利用可能、非表示
1. ユーザビリティの実装
a) ビッグデータ分析シナリオでは、トークンの一意性を利用して、データマイニング、処理、分析の重複排除、統計、関連付けなどの機能を実現します。
b) 情報伝達 その他すべてのシナリオでは、Token はその独自性を利用してシステム全体を循環する平文データを完全に置き換え、交換、関連付け、クエリ、マッチングなどのリンクでのデータ使用を解決できます。
c) 機密機能の使用: 平文データを使用する必要があるシナリオでは、トークン化されたサービスを使用して平文を交換し、完全な使いやすさを実現できます。
2. 不可視化の実装
トークン化自体のセキュリティは、ソリューション全体のセキュリティの基盤です。したがって、トークン化では、不正者がトークンを使用して対応する元の平文を取得し、その結果データ漏洩が発生することを防ぐために、設計から実装までセキュリティを確保する必要があります。詳細については、第 4 章 - トークン化されたセキュリティの実装を参照してください。
3.2.2 基本的なアーキテクチャ要件
複雑なシナリオでデータ保護機能を満たすには、トークン化ソリューションがいくつかの主要なアーキテクチャ要件を満たす必要があります。
- ビジネスへの適応性: トークン化は、オンライン トランザクション、リアルタイムおよびオフラインのデータ アプリケーション、AI や機械学習アルゴリズムなどのすべてのシナリオを含む、すべてのデータ アプリケーション シナリオのデータ交換要件を満たす必要があります。
- セキュリティ: プレーンテキストとの関連付けを保証することで、トークンの非感作属性が確実に保護されるようにします。これは、アルゴリズムとトークン化されたサービスのセキュリティだけでなく、ダウンストリーム アプリケーションの複数のセキュリティによって保証される必要があります。
- 使いやすさと効率性: トークン化の導入により、ビジネス システムの効率性と安定性が向上するものであってはなりません。
3.3 トークン生成ロジック
トークン化のロジックは、企業内の機密データに対してグローバルに一意の ID トークンを生成することです。通常、ID 生成を実現するには 3 つのスキームがあります。
図 5 トークン化の論理図
1. ランダム化 ：完全にランダムにトークンを生成し、1対1のマッピング関係テーブルに格納します（狭義のトークン化生成方法です）。トークンとプレーンテキストの間にはアルゴリズムの関係がないため、前方相関と逆相関はトークン化されたサービスを通じてのみ実行できるため、これが最も安全なソリューションです。ただし、このソリューションの欠点は、トークンの高度な一貫性を確保するために、新しいトークン生成ロジックを同時実行できないことです。そうしないと、1 対多の一貫性の問題が発生します。データの一貫性を確保するために、特定の分散機能とパフォーマンスが犠牲になります。特にリモートのシナリオでは、目に見えないところでユーザビリティのリスクが増加します。
図6 トークン化生成方法1
2. MAC メソッド: 統一されたソルテッド ハッシュ HMAC アルゴリズムを通じて、どのプロセスや場所でも同じトークンを生成して一貫性を確保できます。生成されたトークンと平文の間のマッピング関係は、アンチトークン化機能を実現するためにリストされます。この方法の利点は、リージョン間で分散できることですが、欠点は、特定のセキュリティが犠牲になることです。攻撃者がソルトを取得すると、アルゴリズムを使用してトークンをバッチで計算できます。ソルトに適切な保護メカニズム (暗号化キーと同じ保護戦略を使用) を採用することで、セキュリティと可用性のバランスを実現できます。
図7 トークン化生成方法2
3. 決定的暗号化と復号化: (AES-SIV) や形式保持暗号化 (FPE) などの決定的暗号化アルゴリズムを使用して平文を暗号化し、可逆トークンを生成します。このアルゴリズムは暗号化のセキュリティ技術であるランダム性を破壊しますが、現在のアルゴリズムには一般に抜け穴があるため、使用することはお勧めできません。さらに、このアルゴリズムには当然の抜け穴があります。つまり、キーをローテーションすることができません。
図8 トークン化生成方法3
3.4 トークン化ソリューションの論理アーキテクチャ
図 9 トークン化された論理アーキテクチャ図
トークン化されたサービスは、主にマルチ アクセス統合ソリューションを通じて、すべてのビジネス シナリオの互換性、セキュリティ、可用性を満たす必要があります。そして、必要なセキュリティ対策を統合します。トークン化されたサービスは、論理的にアクセス層、サービス層、ストレージ層に分割されます。
- アクセス層: 主にビジネス アプリケーションと人事アクセスを接続し、トークンとプレーンテキストの間の変換、つまりトークン化と反トークン化の要求要件を完了するために使用されます。マンマシン インターフェイス (ポータル)、サービス インターフェイス (API) 呼び出し、ビッグ データ タスク リクエストをそれぞれ提供します。トークン化されたセキュリティ要件のため、アクセス層は、きめ細かいアクセス制御、IAM、サービス認証、ビッグデータ ジョブ認証機能など、信頼性の高いセキュリティ対策を確保する必要があります。
- サービス層: トークン化とアンチトークン化の実際の実装。主にトークンの生成、保存、クエリを完了します。
- ストレージ層: ストレージ層には主にオンライン ストレージとデータ ウェアハウスが含まれます。セキュリティ上の考慮事項により、トークン化されたマッピング テーブルには平文ではなく、暗号化された暗号文が格納されます。同時に、HMAC アルゴリズムを使用して HASH > トークン > 暗号文の関連付け関係を確立し、平文とトークンの交換 (ポジティブ チェック)、およびトークンと平文の交換 (リバース チェック) のビジネス ロジックを実現します。なお、アプリケーションはトークン化によって平文を直接取得することはできませんが、暗号文を取得し、KMS を通じて復号許可を取得してローカル復号化によって平文を取得します。
3.5 トークン化アプリケーションの概要
図 10 トークン化されたデータ流通のパノラマ
コンポーネントの説明:
1. オンラインデータソース
機密データの主要なデータ ソースは、企業に入力されると、トークン化サービス API に接続してトークンに変換し、ウェアハウスに保存する必要があります。特定のシナリオでは、データはデータ ウェアハウスにも接続されます。データ ソースのもう 1 つの役割は、API、MQ、または S3 やその他のメディアなどの共有ストレージを介して、機密データをダウンストリームに提供および共有することです。
2. データウェアハウスのデータソース
機密データは直接流入またはオンラインからデータ ウェアハウスに入ります。トークン化タスクを有効にしてプレーンテキストをトークンに変換し、それを他のダウンストリーム ビッグ データ アプリケーションに提供する必要があります。
3. トークン化サービス
a) トークン化されたオンライン サービスは、API を介してオンライン トランザクションおよび事実上のタスクにクリア テキスト交換トークン サービスを提供します。
b) オフライン Hive をトークン化し、ビッグ データ タスク用のオフライン データ クリーニング サービスを提供し、プレーンテキストをトークンに変換します。
4. KMS と暗号化と復号化
a) トークン化用の暗号化キーを配布し、平文を暗号化して暗号文フィールドを形成します。
b) 復号権限を持つすべてのアプリケーションに復号鍵を配布し、復号を行います。
5. データの適用
a) 従来の中間アプリケーション: トークンに基づいてビジネス機能を完了できるサービス。データ ソースからトークンを取得し、ダウンストリームに渡します。
b) 復号化アプリケーション: ビジネス要件に従って、セキュリティ ベースラインを満たすことを前提として、トークンを暗号文と交換し、復号化するために暗号化および復号化モジュールに接続して平文を取得します。
4. トークン化されたセキュリティの実装
4.1 トークン化のセキュリティの基礎
トークン化のセキュリティの前提は、トークンと平文の無関係であるため、誰かまたはシステムがトークンと平文の比較辞書を不正に保存および構築した場合、またはこの辞書を構築する能力を持った場合、トークン化のセキュリティ メカニズムは完全に破壊されます。トークン化されたセキュリティの中核は、このテーブルの生成を防ぐことです。
4.2 セキュリティリスクとセキュリティ設計
1. トークン化サービス自体のセキュリティリスクと管理
a)トークン生成ロジックのセキュリティ: ランダム トークンによって生成される一意の ID が最も安全な方法であり、信頼できる乱数生成器が必要です。条件が許せば、ハードウェア ベースの暗号機を使用して乱数を生成できます。ソフトウェアで実装する場合は、暗号化ベースの擬似乱数生成メカニズムが必要です。HMAC 法を使用して生成する場合、塩の安全性を確保する必要があります。
① KMS などの信頼できるメカニズムを通じてのみ作成、配布、保存できます。
② トークン化されたサービスが実行されている場合にのみ使用できます。
③ 定期的に塩をローテーションし、使用した塩は毎日または毎週安全に削除することをお勧めします。
④ SHA-256 や SM3 などの安全なハッシュ アルゴリズムを必ず使用してください。
b)トークン化されたランタイムセキュリティ: トークン化されたサービスは、特別に強化された専用システムを使用します。
c)トークン化ストレージのセキュリティ: ビッグデータのシナリオとさまざまなストレージ要件を考慮すると、トークン化ストレージ自体には機密情報は保存されず、インデックス、トークン、暗号文のみが含まれることが必要です。同時に、トークン化されたストレージには厳格なアクセス制御が必要です。
d)トークン化されたアクセスセキュリティ:
① API は信頼性の高いサービス認証を必要とし、MTLS + Oauth2 チケットが推奨され、同時にアクセス ログ監査が有効になります。
② トークン交換平文ロジックは暗号文のみを返し、リクエストサービスは KMS を使用してローカルで復号し、復号権限を集中制御します。
③ UI は、ユーザーにトークンとプレーンテキストを手動で暗号化および復号化する機能を提供します。要件は IAM を通過し、ABAC ベースのきめ細かいリスクベースのアクセス制御をサポートする必要があります。
2. 環境に優しい上流および下流のサービスおよびアプリケーションによって生成される二次セキュリティ
データ ソースやダウンストリームの平文データ コンシューマに関係なく、トークン化されたインターフェイスのアクセス承認により、リモートからインターフェイスを呼び出し、トークンと平文の間の完全なマッピング関係を横断することが技術的に可能です。したがって、こうした誤った動作やプログラムの抜け穴によってデータが漏洩しないように、セキュリティ対策をこれらのシステムとユーザーにまで拡張する必要があります。
a) データ アプリケーションのセキュリティ ベースラインを構築して、上流および下流のデータ使用動作を制限します。
b) あらゆる形式の違法な平文、特にトークンと平文のマッピング関係データの転送とダンプを厳しく禁止します。
c) プロキシを設定することは禁止されており、データ サービスの主体はトークン化サービスに直接接続する必要があります。
d) すべてのエコシステムは、その後の変更を含め、完全なセキュリティレビューを受けなければなりません。ベースラインのコンプライアンスを確保する。
e) ストレージ、データ インターフェイス、アプリケーション コード ロジック、およびリネージュを含む、すべての上流および下流のサービスを監視システムに組み込む。
f) グローバルな監視とスキャンにより、すべての非準拠プロセスが適時に発見され、処理されるようにします。
5. エンジニアリングの実務経験
トークン化サービスは設計が複雑ではなく、一度実装されると、組織のデータ使用習慣を完全に変え、データ使用効率とセキュリティ コンプライアンスの矛盾を根本的に解決します。
ただし、その強力な保護はデータ使用ロジックの変換に基づいており、平文データを使用する古い習慣を打破します。実装プロセスは、アプリケーション コードの緩いメンテナンス、冗長で混沌とした履歴データ、複雑で混沌としたアクセス ロジックなどの大きな課題に直面しています。これらの問題はシステム変革に障害をもたらすでしょう。機密データを扱うすべての企業は変革に協力する必要があります。この規模のプロジェクトは、プロセス計画、組織的保証、技術サポートの面で調整する必要があります。美団はまた、企業の変革を推進するプロセスにおいて多くの経験を蓄積していますので、参考にしてください。」 。
- 一貫したポリシーの策定とコミュニケーション: 企業レベルのデータ セキュリティ ガバナンス戦略としてのトークン化には、全体的な状況を統一的に理解する必要があります。戦略的要件、特定の実装ガイドライン、ツールと方法などは、明確かつ一貫性があり、コミュニケーションとエラーのコストを削減するために、簡潔な文書を通じてすべての関係者に効果的に伝達される必要があります。その中で、復号化ポリシー、アクセス制御ポリシー、API インターフェイス ポリシー、ビッグ データ、AI などのさまざまなデータ アプリケーション シナリオのセキュリティ ベースラインを完成させる必要があります。さらに、トレーニング、製品マニュアル、インターフェイスドキュメント、その他のチャネルを含む効果的なコミュニケーションチャネルを通じて、すべてのユーザー、研究開発およびビジネス担当者に連絡します。
- 細分化して柔軟に進める: 機密データへのアクセスリンクは長く、その関係は複雑で、ガバナンスレベルの限界と相まって、目に見えない形で変革の難しさと心理的および実際の投資のプレッシャーを増大させています。変換ロジック ユニットをサービス レベルまで水平および垂直に分割して、断片化されたグレースケール変換を実現し、変換をより機敏にします。
- DevOPS 変革: トークン化はデータ使用のロジックを変更するため、すべてのビジネスおよび研究開発投資によって実行する必要があります。人件費は膨大であるため、変換ロジックをシンプルで使いやすい SDK にカプセル化することで、変換の難しさと人的エラーによって引き起こされるリスクを軽減できます。さらに、テストと受け入れは、自動スキャン、データ クリーニング、受け入れ、検出ツールを使用して、ビジネス セルフサービスの閉ループによって完了できます。
- トークン化サービス機能: 変換後、トークン化は一部の関連アプリケーションに強く依存するようになり、トークン化の障害やパフォーマンスの問題がビジネス アプリケーションに直接影響する可能性があります。したがって、トークン化されたサービスのパフォーマンス、可用性、安定性は非常に重要であり、専門チームによって慎重に設計され、障害を避けるために継続的にテスト、検証、最適化される必要があります。同時に、セキュリティに基づいて一定の劣化耐性や耐障害性を提供することも必要です。
- 運用とガバナンス：プロジェクトの進展に伴い、トークンは平文を超えて主流となり、主要なデータ入力と主要なデータ提供者を制御することで、組織内でデフォルトでトークンが使用されることを保証し、デフォルトのセキュリティを実現します。 、企業のコールド データ、静的データ、または比較的独立した島のデータでも、依然として漏れやリスクが発生します。したがって、すべてのデータサポートシステムのスキャンやモニタリングなどの多次元認識機能をサポートする必要があります。同時に、異常なデータは特定のビジネスにマッピングされ、トークンが完全にカバーされるようになります。
- 学習、改善、反復: デジタル イノベーションの進化に伴い、新しいデータ形式やデータ アプリケーションが追加され続けるため、プロジェクトはこの変化に対応し、長期的な戦略を保証するためにツールとプロセスを継続的に改善する必要があります。
6. 対象外の事項
将来的には、データ セキュリティ ガバナンスは拡張され続けるでしょう。
データ レベルでは、トークン化は写真やビデオなどの非構造化データを解決しません。暗号化を直接渡すことが必要な場合があります。トークン化は、企業の信頼境界を越えたデータ交換の問題を解決するものではなく、プライバシー コンピューティングやマルチパーティ セキュア コンピューティングなどの新しいテクノロジーが必要です。トークン化の主な目的は、DB と Hive に保存されている構造化された PII 情報です。JSON に隠された半構造化データや、ログやファイル内の非構造化 PII データは処理されないため、強力なデータ検出ツールとデータ ガバナンス ツールを使用して処理を完了する必要があります。
データ セキュリティ システム全体から見ると、PII は大海の一滴に過ぎません。トークン化は実際には企業の内部データ使用シナリオを解決するだけですが、デフォルトのセキュリティと設計セキュリティの前例となります。PII 情報は個人の機密情報の中核となるデータであるため、メリットとデメリットをトークン化し、データ収集までソースを追跡し、三者間のデータ交換に拡張することができます。さらに、トークンの関連付け解除を通じて、ロスレス データ削除やその他の機能を実現できます。
データセキュリティは大きな問題であり、特にデジタルトランスフォーメーションの強力な開発需要の下では、複雑なデータアプリケーションに直面して、ネットワークセキュリティにはさらなる技術革新が必要です。私たちは、イノベーションへの安全なパスであるトークン化を通じてより多くのデータを刺激することを望んでいます。
7. この記事の著者
Zhigang 氏は Meituan のセキュリティ アーキテクトであり、暗号化、クラウド ネイティブおよび DevOPS セキュリティ、データ セキュリティ、プライバシー コンプライアンスの専門家です。