FinTechでも現実に近いデータでテストしたい――データへのアクセスとセキュリティのバランスを取る方法6選：「ID情報をマスクする」「アクセス許可の原則に従う」など

ソフトウェアテストでは実データの利用が役に立つとしても、実データのセキュリティとプライバシーを侵害しないよう注意しなければならない。本稿では、FinTechのソフトウェアテストを行う場合に中核とすべき6つの方針について説明する。

[Matt Heusser，TechTarget]

　FinTech（フィンテック）でのソフトウェアテストでは、実際の顧客データが最も強力で現実的なシナリオをもたらす。だが、規制や標準によって、あるいは自社のセキュリティチームによって、実際の顧客データの使用が許可されなかったり、アクセスを制限されたりする可能性がある。

　セキュリティ担当者の判断は間違いではなく、企業には顧客の社会保障番号、生年月日、姓名を非公開にしておく義務がある。個人を特定できる情報（PII）は誰の個人情報であっても、盗難に遭ったり、詐欺に使われたりする可能性がある。実際に使われているクレジットカード番号など、PIIに関係する機密データをテストに含めると、詐欺や悪用を助長する恐れがある。

　テスト担当者が実データを使いたいと思うことも間違いではなく、運用環境で実際に見られる状況を作り出すことが最善のテストになる。実際に使われているデータを利用すれば、テスト環境でも運用環境でもソフトウェアが一貫して動作する可能性が高まる。

　幸い、セキュリティと優れたテスト手法のバランスを取れる方法がある。本稿で示す方針の大半は、トランザクションシステム（保険金請求処理、毎月の請求、利息の計算など）を対象とするが、PIIを扱う全てのシステムに当てはまる。こうしたシステムのテストには運用データが使用される懸念がある。

FinTechのテスト向けに中核となる6つの方針

　本稿で紹介する6つの方針は、ソフトウェアチームがFinTechのテストの精度を上げながらデータセキュリティとのバランスを取るのに役立つ。

ゴールデンマスターを使う

　大半のシステムでは、最低でもバックアップの目的で、データのエクスポートとインポートが可能だ。ゴールデンマスターとは、この考え方を一歩進め、テストデータの簡単なサンプルセットを作成することを指す。このデータセットには、信用度の低いユーザー、信用度の高いユーザー、法的には契約できない18歳未満のユーザーなど、よく知られるケースを含める。

　よく知られ、一貫性がある適切なデータを用意すれば、テストチームは静的テストケースを作成して、毎回の実行で同じユーザーに対して同じ想定結果が得られるかどうかをチェックできる。最も簡単なオプションは、ゴールデンマスターへのエクスポートをバージョン管理ツールやデータ管理ツールに格納することだ。場合によっては、ゴールデンマスターへのエクスポートに保険請求日などの日付が含まれることがある。その場合は、インポート時にこの日付を更新する必要が生じる可能性があることに注意する。

ID情報をマスクする

　ID情報盗難のリスクを最小限に抑えるため、運用データにマスキングを施す。このマスキングでは、氏名、生年月日、社会保障番号などの情報を取り出し、有効な形式を保ったまま内容が分からないように変更する。そうすれば、機密データを保護したまま、現実的で正確なソフトウェアテストを実行できるようになる。

　とはいえ、変換前のオリジナルデータにアクセスされるという問題は残る。そのため、内容が分からないように変更される前の「上流工程」のデータにテスト担当者やプログラマーがアクセスできないようにするセキュリティ制御を備えるデータマスキング自動化ツールも幾つか存在する。

アクセス許可の原則に従う

　保険会社に勤務していた当時、現在日に個人が保険に加入しているかどうかを確認する簡単なコードライブラリを作成したことがある。このライブラリの単体テストには、自分自身の個人情報を使用した。自分自身の個人情報にアクセスすることを会社に許可していたので、HIPAA（医療保険の相互運用性と説明責任に関する法律）違反にはならない。退職する際には、他の開発者がこの方針を受け継ぎ、コードのメンテナンスを行っている。

　このアプローチ自体は適切に機能する。だが、同じデータベースで同時に多数のテストを実行するときには理想的ではない。そのため、個人IDへのアクセスを許可するアプローチは、合成ユーザーの準備が整うまでのつなぎとして使用する。

合成ユーザーを使ってテストする

　テスト担当者が、例えば年齢や信用度などに基づいて特定のタイプのユーザーを要求すると、一意のユーザーIDを返すコードライブラリを用意するのが合成ユーザー（synthetic users）を使ったアプローチだ。全てのテストで新しい合成ユーザーを要求すれば、複数のテストに同じユーザーが再利用されてデータベース内で「競合」が発生するという事態は起きない。例えば、テストで1人の合成ユーザーに何度もローンを申請すると、その合成ユーザーの信用度が過剰に高くなるという新たなシナリオに陥る可能性がある。

カスタマーサービスと連携する

　通常、カスタマーサービスにとっては、運用データの一部へのアクセスが不可欠だ。運用環境で問題が発生した場合、運用環境の問題をデバッグし、切り分け、解決するために、カスタマーサービスが情報を提供する。こうした情報を提供できるかどうかがテストの重要な側面になる。テスト時に運用データの一部にアクセスできるようにするには、このプロセスを正式なものにする必要がある。

大量の自動テストを使用する

　毎日数千人のユーザーを対象に差し込み印刷用のテキストファイルを作成する企業に勤務したことがある。このとき、ビルドのたびに、前回の運用データのゴールデンマスターを2つ用意し、これで現運用バージョンと新しいビルドのソフトウェアを実行し、双方の出力を比較する自動テストを作成した。その結果、実行できるテストケースの数が、数日間で数十件から、数時間で数千件に増加した。

　規制の厳しい業界なら、この自動テストにデータのマスキングやランダム化を組み合わせる必要があるかもしれない。例えば、年齢や信用度別に運用ユーザーを分析することで、運用での使用に合致する合成ユーザーのゴールデンマスターを作成できる可能性がある。