データ保護｜CoSort9　ソリューション概要

データ保護

フィールド・レベルでの監査可能なデータ保護

フィールド単位のデータ保護
ファイルの機密データ・フィールドだけを対象にする先進的な暗号化
データ保護の事例考察
優れたアルゴリズム
データ変換やレポーティングの同時処理
機密データをファイルから除去する
個人データを匿名化する（復元できないデータ保護）
機密データの暗号化（復元可能なデータ保護）
テーブル・ルックアップ機能によるセキュリティ（復元可能なデータ保護）
証券会社での利用例――SortCLによるスクリプト例（フィールド・レベルの個人データ保護）

フィールド単位のデータ保護

個人情報保護法の施行や金融商品取引法（J-SOX）・新会社法の施行などにより、ますます企業のコンプライアンス（法令遵守）が重要視されるようになりました。また個人情報に限らず、知的財産や営業秘密、財務情報など、保護すべき情報は企業内に多く存在し、そのほとんどはデータ化され、常に内部からの流出や改竄・削除の危険にさらされています。
従来、それらデータの保護は従業員のモラルに依存していたのが現状でしたが、法制度の整備に伴いIT統制の必要性が再認識され、このようなデータ・セキュリティへの課題を解決し、 IT基盤の強化に取り組む企業が増えています。
CoSortはこのようなデータ・セキュリティ課題を抱える企業の、コンプライアンス対応、情報保護対策などを包括的に解決し、IT基盤の強化を行う事が出来る最適なソリューションです。

リスクに応じて的を絞った監査可能なデータ保護

CoSortのSortCLツールに、データ・ファイル内の機密情報をフィールド・レベルにまで掘り下げて保全する機能群が加わりました。（CoSort以外のデータ保護ライブラリを利用する機能もあります。）このツールを使えば個人情報など機密情報を含むファイルの取り扱いにおいてコンプライアンスを確保し、安全なアウトソーシングを行うことが可能になります。その際、データ処理やレポーティングに支障が生じることはありません。
CoSort のSortCLツールでは、複数のプライバシー保護手法（データ・マスキング機能）を使ってデータ保護を行うことができます。CoSort Version 9で以下の機能が追加されました。

フィールド・レベルのencryption暗号化
anonymization（匿名化←筆者不明）＝復元できないデータ変換、pseudonymization（偽名化←ペンネーム）＝復元できる擬似データ
de-identification（識別不能化）＝エンコード
re-identification（再識別化）＝デコード
アウトプット・ファイルから機密のフィールドを削除する
実際のファイル・フォーマットを使って安全なテスト･データを作成する
コンプライアンスを検証するためのジョブ単位のXMLで記述された監査証跡
これらの機能を使うことにより以下のような多様なアプローチが可能となります。
ファイルごとに複数のフィールド・レベルの保護技術を活用することができます。企業データの一元管理、個人情報、セキュリティの各責任者は、それぞれのニーズに応じてフィールドごとに最適な技術を選べます。
機密フィールドのデータのみを保護します。データ処理やレポーティングやアウトソーシング等の目的でファイルの機密フィールド以外のフィールドにアクセスし、それらを使用することは従来通り可能です。
あたかも本物に見えるようなダミーデータを作成します。（例えば偽名化、テストデータ、ビット操作等。) この場合も、ファイルは共有できますし、従来通りにレコードやフィールドを操作できます。
CoSortの256ビットAES（Advanced encryption Standard）関数をお使いの暗号化ライブラリに追加します。 CoSortのSortCLは、このNSA（National Security Agency）規準の関数をそのまま使ったり、任意の関数にリンクしてロードしたりして、必要な個人データのフィールドを暗号化および復号化できます。
ランダムに生成されたか、またはランダムに選択された、一つまたは複数のフィールドで安全なテストデータを作成します。

同時にデータ変換やレポーティングを行うことはもちろん可能です。
フィールド・レベルのデータ保護機能と、高性能な並列処理データ変換機能や、レポーティングや、データ受け渡し機能を、組み合わせて使うことができるのは、 CoSortのSortCLツールだけです。その理由は、SortCLのデータ保護機能がSortCLのデータ変換の拡張として追加されたもので、一つのジョブ・スクリプトと一つのI/Oパスで動作するようになっているからです。データを保護しながら、離れた場所でデータを処理し、保存し、表示するといったニーズに対して、 CoSortのフィールド・レベルでの統合セキュリティ機能は、重要な選択肢となるでしょう。

ファイルの機密データ・フィールドだけを対象にする監査可能な暗号化

課題：データ・プライバシーの侵害

― 氏名、住所、クレジットカード番号、パスポート番号、電話番号などの漏洩 ― は、増大しつつある身近な危険です。企業や政府機関では、機密情報を他の情報と共に保存、送信、移動することが不可避になっています。
個人を特定するフィールド（.txt、.csv、.sam、.dat、.xml、および同様のファイルにあるカラム・データ）を保護するのに何が可能であり、また、何がプライバシーに関する法律に適合しているのでしょうか。
このようなファイルが、異なる記憶装置や印刷物に存在しているときや、またデータベース、表計算、Eメール、ファイアーウォール、ラップトップ・コンピューター（紛失しやすい）でこれらのファイルのフィールドの入出力を繰り返しているときには、データの保護は極めて困難です。
現在の一般的な機密保護（ファイル、データベース、ディスク、ラップトップでの暗号化を含む）は、保護を必要とする機密フィールドだけでなくファイル全体に対してアクセスや使用を制限するというものです。これまでの機密保護対策は過剰に行われているだけでなく、データを分離することで処理が遅くなったり、高価なセキュリティ・ソフトウェアや装置の使用を伴ったりする場合があります。

解決策：

ファイルのフィールドを暗号化するには、別途ツールを用意しなければいけないと考えていたかもしれませんが、Unix、Linux、Windowsで利用できる256ビットAESライブラリがCoSort Version 9のSortCLツールにバンドルされています。次のような理由で、CoSortの使用は、ベストなデータ・セキュリティ対策であるといってもよいのではないでしょうか。

CoSortによるソリューションであれば、1つのジョブ・スクリプトおよびI/Oパス内に、任意の数、サイズ、タイプ、位置のフィールド、レコード、ファイルを指定できます。アプリケーションを合成したり、負荷をかけるために、さまざまな選択をしたりして範囲基準を適用できます。 SortCLでは、ランダムなデータと実際のデータを組み合わせて、同時に他のフィールド・レベルのデータ保護テクニックを使用できます。本番ファイルのレイアウトの定義にすでにSortCLを使用している場合、（CoSort9またはRowGenで）同じメタデータを使用して同じフォーマットで安全なテストデータを作成できます。 CoSortより低価格のRowGenツールを使用している場合、テストデータの定義に使用しているものと同じメタデータをSortCLに移行して、実際のデータの生成時に同じフォーマットに変換されるようにできます。

機密保護が必要なフィールドのみで暗号化されます。つまり、ファイルの他のフィールドや他のデータ資産は、そのままオープン状態で利用できます。
CoSortによる暗号化は、コンピューターの処理能力（リソース）にほとんど負担をかけません。
CoSortでは、それぞれのフィールドごとに異なる暗号キーやライブラリを適用できるため強力なセキュリティの実現が可能で、ロールに基づいたアクセス･コントロールのフレームワークに準拠できます。
CoSortでは、匿名化、非識別化、偽名化、マスキング等の、CoSortの（あるいは既存の）他のフィールド保護の方法も並列処理で使用することが可能となっています。
フィールドごとのセキュリティ機能と日常的なデータ変換やレポーティングのルーチン処理を同一のジョブ（およびI/Oパス）の中で実行することが可能です。このようなセキュリティ機能の使用は、従来のものと比べより効率的であるだけでなく、さらに暗号化されたフィールドを処理したり提供したりすることをも可能にします。
CoSortでは、ファイルに保存されているフィールドを暗号化するために複数のライブラリとキーの選択が用意されています。また、そのライブラリとキーは、特定のハードウェア・プラットフォームやデータベースに依存しません。アウトプット・ファイルの暗号化されたフィールドは適切なキーによって復号化されるまで安全性を失うことはありません。
CoSortでは、同じジョブ・スクリプト内で復号化、データ処理、再暗号化のすべてを行うことができます。これにより、中間の処理ステップでCoSortが使用されない場合でも機密フィールドの安全は保たれます。
CoSortのSortCL用のXML記述の監査証跡により、誰が、いつ、どこで、どのようにしてデータを保護したのかを知ることができます。機密性に対する要求を満たしていることを証明する必要があるということを忘れないでください。
またCoSortのSortCLツールで、必要とあれば、仮の（テストのための）データを生成することもできます。

危険にさらされているデータに対して他に例の無い統合化を実現したCoSortのフィールド・レベルの暗号化の機能の詳細について、下記をお読みください。

データ保護の事例考察
優れたアルゴリズム
データ変換やレポーティングの同時処理

データ保護の事例考察

データベース全体や、そのデータベースのフィールドを、保存中の静的状態において単に暗号化するだけでよいのでしょうか？ストレージに保存されている静的なファイル内のフィールドを保護するだけでなく、処理の過程の動的なファイル内のフィールドも保護することが可能になりました。
CoSortのSortCLツールは、データ・ウェアハウス分野のETL（Extract Transform Load）処理やODS（Operational Data Store）処理において、ファイルのステージングや統合を行う際に広く使われています。 SortCLは、抽出（Extract）したデータベース・テーブルを変換（Transform）し、大量データのデータベースへの書き込み（Load）を高速化するため、フラット・ファイルを事前にソートする等の日常的なルーチン処理に使われています。フィールド・レベルの暗号化とその他のデータ保護技術の導入により、セキュリティが施されたフィールド（静的なデータ）を持つデータベース・テーブルを書き込んだり、抽出したファイル、レポート等のフィールド（動的なデータ）を保護したりすることが可能となります。
フィールド・レベルの暗号化がプライバシー規制に準拠することにいかに役立つかは、電子的個人健康情報（EPHI）の保護を目的とする、2003年施行のHIPAA（医療保険の相互運用性と説明責任に関する法律）のセキュリティ規則最終版に提出したCoSortのSortCLの提案書類に示されています。

セクション164.312（技術的保全）には、提案された規則(提案規則)の二つのセクション ― テクニカル・セキュリティ・サービスとテクニカル・セキュリティ・メカニズム ― から抜粋された条項が含まれています。実施しなければいけない必須条項は以下のとおりです。

＊EPHIを維持するシステムにおけるアクセス・コントロールの技術的ポリシーと手順です。これらのシステムでは、独自のユーザー識別方法を認め、緊急時に必要なEPHIを得るための緊急アクセスの手順を含んでいなければなりません。 HIPAAのセキュリティ規則最終版の必須でないAddressable Implementation Specifications （委任可能な実現仕様）には、自動ログオフとEPHI暗号化／復号化メカニズムが含まれています。

フィールド・レベルのコントロールによって、複数の暗号化ライブラリとフィールドごとに必要な人だけが復号化を行う権利があるパス・フレーズを使うことが可能です。

＊伝送セキュリティ、これは次の二つのAddressable Implementation Specifications （委任可能な実現仕様）を含んでいます。
1. データの完全性を管理する―　電子的に伝送されるPHIが、不適切に改ざんされ、削除されるまで発見されないというようなことがないことを確実にするセキュリティ対策
2. 暗号化―　オープン・ネットワークでは暗号化を明示する必要があるという提案規則の主張から発展して、暗号化の明示ということが重要問題になっています。今や、対象事業者は、関連する危険の程度に合わせて、いかにしてEPHIを保護するかを決定しなければならない時です。対象事業者は、HIPAAの規則の前文において、EPHIを伝送する際は、特にインターネット上では暗号化技術の使用を考慮するよう勧告されています。このような変化の重要な理由として、HHS（the United States Department of Health and Human Services）は、小規模のプロバイダーへのコスト負荷とEメールに暗号化に対する簡単で、互換性のある解決法が欠けていることを挙げています。

SortCLは、暗号化と同じように、データの操作やレポーティングをしながらフィールド・レベルで行えるフィルタリング、復元できないデータ変換、復元できる擬似データ等の選択を用意しています。

＊監査統制のためのハードウェア、ソフトウェア、小規模ルーチンによる監査管理の機能

統計情報や即座に参照可能なXML形式の監査ログの取得といったSortCLの機能、ジョブ・スクリプトや暗号化ライブラリの記録は、EPHIフィールド・データがいつ、どのように、誰によって暗号化（または他の保護対策やデータ変換）がなされたかを示すために使われます。

＊データの正確性を確実にして不適切な変更や破壊からEPHIを保護するための方針と手順。この正確性の基準は、許可されていない方法でEPHIが変更されたり、破壊されていないことを確認するためのメカニズムを述べるAddressable Implementation Specification （委任可能な実現仕様）と一対のものです。

正しい暗号キーで復号化しないデータは、復号化されたフィールドの信頼度が落ちたことを示しています。 SortCLの実行時に作動する統計情報と監査ログの取得によってこのようなデータを追跡することができます。これらのファイルから、いつどのようにしてフィールド暗号化が施されたかを知ることができます。

＊ユーザーやアクセスの実体の認証、この認証で対象事業者は、 EPHIにアクセスしようとしているユーザーやアクセスの実体がアクセス権を持っていることを確認する手順を実現するよう求められています。

パス・フレーズは、フィールド・データの暗号化と復号化のためのキーを生成するのに使われます。ですから、正しいパス・フレーズを持っているユーザーやアクセスする実体のみがフィールドを暗号化または復号化できるのです。
上記の技術のすべては、単独で行うことが可能で、１つ以上のファイル上で同時に実行も可能ですし、同じSortCLのスクリプト中に他のデータ変換やレポーティングの処理があってもかまいません。 Logon SecurityというUnixシステムへのアクセスをコントロールするセキュリティ製品がIRIから購入可能です。この製品は、システム・アクセス開始時の監査ログを暗号化するものです。

優れたアルゴリズム

CoSortの256ビットAESライブラリとその他の暗号化関数

CoSortのSortCLツールのユーザーは、任意の暗号化ライブラリを使って、フィールド・レベルでデータを保護することができます。しかし、NSA（National Security Agency）のSuite B－レベルのセキュリティ基準を満たすために、CoSortは、現在最強である256ビットAES（Advanced Encryption Standard）をSortCLに実装していて、ユーザー固有のパス・フレーズ（暗号キー）で実行することができます。暗号化されたアウトプット・フィールドは、データ処理やレポーティングのために印刷可能な文字で表示されます。
パス・フレーズは、フィールド・データの暗号化と復号化のためのキーを作るために使われます。ですから、データを復号化できるのは、適切なライブラリとパス・フレーズを所持しているユーザーだけです。CoSortの暗号キーの安全性を高めるため、サードパーティのキー・マネジメント・システムをCoSortと共に使用することを推奨します。
SortCLのフィールド・レベルのデータ変換でカスタムという意味は、ユーザー自身の暗号キーや代替の暗号化ライブラリやその他のフィールド保護機能をユーザーが指定することが可能で、またファイル定義のどこででも指定することが可能であるということです。ユーザーは、Twofish、3DES、あるいはその他のアルゴリズムを任意に選択して使うことができます。
暗号化の改善やプライバシー規則に対するコンプライアンスの検証を目的として、クエリ可能な監査ログの出力を指定することができます。XML形式のログには、使用した暗号化ライブラリのパス・ファイル名を含むすべてのスクリプトとフィールドごとに適用した保護機能が記録されます。

データ変換やレポーティングの同時処理

CoSortの暗号化は、ファイルへのアクセスと処理効率を低下させません。

『ファイルの安全性確保と可用性を両立させます。』
CoSortのSortCLツールは、大規模なファイルをフィールド・レベルで高速に暗号化し、印刷可能な文字でこれらのフィールドを表示します。これにより、ユーザーは個人情報のフィールドも、そして個人情報でない残りのフィールドも適当なツールで処理することができます。別な言い方をすれば、ユーザーはファイルを保護しながら、個人情報の侵害というリスクを排除して、データの操作、データベースへの書き込み、報告のための配布などにファイルを使うことができます。ETL、ODS、データベース、ビジネス・インテリジェンス（BI）等の実行に際して、重厚長大なセキュリティ対応をしないでも、データを円滑かつ安全に走らせつづけることができます。

『ジョブ・ステップを統合し、コンピューティング・リソースを節約します。』
CoSortのSortCLツールでは、暗号化はその他のデータ保護技術と同じく、フィールド・レベルのデータ変換の一種です。これにより、フィールド・レベルの暗号化オペレーションを、ファイル・システムで実行したい他のフィルタリング、変換、フォーマットの相互変換、フォーマット機能等と共に、同じ製品、同じ場所、同じアクセス権の中に統合することができます。SortCLによって、並列処理データ変換とレポーティングを行いながら、同時に独自の方法でファイルを保護（暗号化）できます。

Operational Risk Management with CoSort9

CoSort V9の性能評価において、SortCLのAES暗号化により増大するマシン負荷は、最小限であるということが示されています。フィールドの暗号化を同じジョブと同じI/Oパスで実行するのがすぐれているのは、次の点です。

複数のフィールド・レベルの暗号化ライブラリとキーの使用
他のフィールド・レベルのデータ保護技術の使用
複数かつ大量のデータ変換
レポーティングとBIビジネス・インテリジェンスのプレゼンテーション
安全なテスト・データの生成

CoSortのSortCLによって、同じジョブ・スクリプトで復号化、操作、再暗号化のすべてを行うことができます。上記の方法により、データ操作のプロセス間で機密データが外部に漏洩するのを防げます。

機密データをファイルから除去する

課題：

機密データの一部には、将来的に処理ステップが不要なデータがあり、目的のファイルやレポートにどんな形であれ、現れないようにしなければならない場合があります。そのような場合には、データソース内の個人データ・フィールドが出力結果に現れるのを防がなければなりません。

解決策：

ユーザーがファイルを操作するとき、必要な人にだけ知らせるという原則に基づいて、入力フィールドがどの出力レポートや受け渡しファイルに行くのかを選択できます。 CoSortのSortCLツールは、条件判断のロジックに基づいてレコードを選択的に除外したり、出力の際に特定のフィールドを削除したりすることができます。

個人データを匿名化する（復元できないデータ保護）

課題：

元のフィールドに保存された個人や関連項目が特定できないように、そのデータの内容を永久に変えてしまうことが必要になるケースもあります。データが変換されると、元のデータ内容と結びつくものは何も無くなります。このデータ保護方式では、元のフィールドの配置（カラム、サイズ、データタイプ）がそのまま変わることはなく、テスト環境でテスト・データを本物らしく見えるようにできるという点ではフィルタリングや暗号化よりも優れています。

解決策：

CoSort V9のSortCLツールは、データ変換やレポーティング処理をしながらフィールド・レベルでファイルの不透明化やマスクを行います。実際に、SortCLを使って機密フィールド・データの復元できないデータ保護を行うには、以下の方法があります。

数値データに三角関数や他の数学関数を使う
バイト・シフト、データ操作、タイプ変換
文字データは代替文字によるマスキング
ユーザー独自のフィールド・レベル関数によるデータ変換

選択する方法により匿名化されたフィールドや復元するフィールドのありそうな値の変換結果が決まります。これらの手法は、危険性からデータを保護するために、暗号化、識別不能化、ペンネーム化などを含むデータ保護機能で、SortCLが提供している機能です。

機密データの暗号化（復元可能なデータ保護）

課題：

元のフィールドに保存された個人や事項が特定できないようにする場合でも、そのデータの内容を復号化（デコード）することを前提に暗号化（エンコード）することが必要なケースがあります。データは、異なる部門間を安全に流すことができ、必要があれば復元可能でなければならないという場合です。機密フィールドのデータを別の出力データに変え、必要に応じて元に戻します。

解決策：

CoSortのSortCLツールには、データ保護された情報や他の個人情報フィールドのデータ（社会保障番号や携帯電話の番号など）を識別不能化するいくつかの方法があります。それら機能の実行結果は本物らしく変換され、そして次のようにして識別不能化されたフィールドを再識別化します。

機密情報のフィールドの値を別名に置き換えるルックアップ（SET）ファイルを指定する。
フィールドをASCII文字で暗号化する、識別不能化の組み込み関数を使う。
複数のSortCLデータ操作組み込み関数でフィールドを変換する。
独自のフィールド・レベル関数を使ってデータを識別不能化または暗号化する。

関数ベースの識別不能化機能の例 (gui2scl) この例ではファイル内のフィールドSSNが識別不能化されています。

これらのフィールド・レベルの識別不能化の機能によって、個人情報の保護基準に準拠するとともに、データやファイルをさらに有効に処理することを可能にします。しかし、暗号化が実現しているような強固なセキュリティと復元性を提供するものではありません。

フィールド・レベルの偽名化

テーブル・ルックアップ機能によるセキュリティ（復元可能なデータ保護）

課題：

フィールド中の個人を特定するデータを擬似データに置き換えたり、表示の際に本物に似せた代替データを出力したりすることが必要な場合があります。

解決策：

扱われるデータ・セットが小規模であれば、CoSortのSortCLツールを使用することによって、簡単な方法で個人データを隠しながら、内容は判らないけれどもそれらしく見えるような置換データを出力することができます。元のフィールド・データに擬似データを割り当てるために SETファイル内のルックアップ・フィールドの位置を指定します。データベースの多次元テーブルのルックアップに類似の、テーブル・ルックアップ機能により、他のデータ保護の方法よりも代替データをよりリアルに見せることができます。
擬似データで、データを処理し、共有し、再識別化することができます。そのとき元のデータやルックアップ･パラメータにアクセスがあります。