多様化するFinTechに不可欠な 「セキュア・バイ・デザイン」｜上流工程がセキュリティー品質確保の鍵を握る

　様々な外部サービスが連携するFinTech関連システムでは、セキュリティーをいかに確保するかが大きな問題となる。その際に有効なのが、要件定義などの上流工程でセキュリティー要件を検討し組み込む「セキュア・バイ・デザイン」の考え方だ。早い段階で手を打っておけば、直前に脆弱性が見つかり、サービスの提供を延期するといった事態を回避できる。

はじめに

　FinTech/デジタル技術を活用した金融サービスが広がるにつれて、セキュリティーをどのように確保するかがこれまで以上に重要な課題として浮上している。金融機関、ITサービス会社、クレジットカード会社、決済代行会社などのサービスやシステムが複雑に絡み合うなか、セキュリティーの品質を高めていくのは容易でない。しかもこの1、2年でFinTechサービスを狙ったサイバー攻撃は急激に増加しており、手口も巧妙化・組織化されてきた。

　こうした状況に対し、有用なセキュリティー対策の1つとなるのが「セキュア・バイ・デザイン（Secure by Design）」である。「企画・構想」「要件定義」「基本設計」といったシステム開発の上流工程で、必要な対策を盛り込む考え方を指す。

　特に様々な外部サービスと連携したサービスを実現する際に、詳細設計以降の下流工程でセキュリティーの不備が見つかると、手戻りが生じてコストやスケジュールに多大な影響を与えてしまう。さらに、サービスそのものの存続が危ぶまれる事態にも発展しかねない。生命保険会社A社の例を示そう。

　A社は保険窓口や営業担当者の業務負荷軽減を狙い、契約者向けのスマートフォンアプリを開発した。API（アプリケーション・プログラミング・インターフェース）経由で契約情報を参照・変更できるとともに、生活に役立つ情報を提供するものだ。

　A社は様々な利用形態を想定したセキュリティーの検証が不十分なまま、設計・実装・テストを進めた。すると、リリース間近の脆弱性診断で重大な不備が大量に見つかった。同社は不備に対応するために、システム構成や認証・認可フローの見直しを進めた。それが連携処理やデータの不整合を引き起こし、多大な追加工数が発生してリリースは大幅に遅延した。何とかサービスを開始できたものの、いくつかの主要な機能は間に合わず、当初の目標を達成できなかった。

　こうした事態を回避するためには、セキュア・バイ・デザインの考え方を取り入れて、セキュリティー要件の抜けや漏れをできるだけ上流工程で防ぐ手立てを講じることが望ましい。以下、主に金融機関がFinTechサービスおよびシステムを開発する場合を想定して、セキュリティー対策をどのように盛り込めばいいかを工程ごとに見ていく。

リスクへの対応方針を判断

　企画・構想の工程では、システムやサービスの目的・用途を整理したうえで、システムの重要度に応じてセキュリティーの要求水準を設定する。

　重要度は、主に以下の4点に着目して判定する。

（1）情報資産の重要度・量

　システム停止やデータの改ざん・漏洩が生じた際の被害範囲と深刻さを基に、保有する情報資産の重要度を定義する。例えば顧客データは「ランク1」、取引先データは「ランク2」などとする。

（2）システム・情報資産の場所

　システムの設置場所や情報資産の保管場所を、インターネット接続の可否、外部からアクセス可能か、などで分類する。特に外部からの不正アクセスのリスクについて入念に検討する必要がある。

（3）ユーザーの種別・数

　ユーザーの属性と規模を基に、被害発生時にサービスに与える影響（レピュテーション［評判］やパフォーマンスの低下、販売機会の損失など）を推定する。

（4）他システムへの影響

　システムの停止やデータの改ざんが生じた際に、連携しているシステムにどのような影響を与えるかを推定する。

　さらに、それぞれのシステムにおいて想定されるセキュリティーリスクを、脅威・脆弱性の両面から洗い出す。各リスクについて、発生可能性や顕在化した際の影響度などを可視化し、システムの重要度を踏まえてリスクを評価・分析する。

　その結果を基に、費用対効果を考慮しつつリスクへの対応方針を決めていく。例えば、優先度が高いと判定したリスクについては回避または低減するための対策をセキュリティー要件として抽出し、設計に盛り込むことにする。優先度が低いと判定したリスクは保有または移転（リスク負担を第三者に転嫁）するものとし、セキュリティー要件から除外する。

セキュリティー要件を詳細化

　要件定義の工程では、企画・構想で定義したリスク対応方針に沿って、セキュリティー要件を詳細化していく。その際に、対策の「広さ」と「順序」の2点に着目して進める。セキュリティー要件は曖昧なものになりがちだ。2つの視点を用いることで抜けや漏れを防ぎ、適切な粒度で要件を定義できる。

＜広さ：対策すべき領域を網羅的に把握＞

　セキュリティーの技術面における対策領域の全体像を把握し、セキュリティー要件を展開していく。主に技術面に着目した領域は大きく、基本領域（アカウント管理、認証、アクセス制御、データ保護、バックアップ）と共通領域（構成管理、マルウエア対策、脆弱性管理、ログ管理）で構成される。

　基本領域は、システムが扱う情報資産へのアクセスに着目した一連の対策を指す。共通領域は、基本領域を補完してシステムを健全な状態に保つ役割を果たす。例えば「構成管理」ではシステムを安全に構成して、「脆弱性管理」などに用いる構成情報を管理する。

＜順序：対策を防御の時系列に沿って検討＞

　対策領域ごとに、時系列に沿って要件を詳細化していく。ここではNIST（米国立標準技術研究所）の「Cyber Security Framework」で定義された5つの視点を用いる。

• （a）特定：攻撃から守る対象を把握
• （b）防御：攻撃の試行をブロック
• （c）検知：防御事象を即座に検知
• （d）対応：暫定対策で被害拡大を防止
• （e）復旧：平常時の状態に戻す

　例えば、アカウント管理での特定とは「IDやパスワードの付与ルールやセキュアな保管場所を確認・整理」、防御とは「ディレクトリーサービスのポリシーを活用して強固なパスワードルールを適用」といった対策を指す。

　このように対策の広さと順序を意識して「セキュリティー要件定義書」としてまとめ、要件の妥当性についてシステムの所管部門やIT部門、設計担当者などで確認し、工程完了の判定を行う（通常の要件定義書に組み込むこともある）。

　さらに、ITサービス事業者がFinTechに参画する場合、金融業界では当たり前となっている基準を順守する必要がある。高い信頼性とセキュリティーが求められる金融システムにはFISC「金融機関等コンピュータシステムの安全対策基準」、決済サービスと連携させるには、PCI DSS（Payment Card Industry Data Security Standard）への準拠が必要で、当局の検査を受けた際に適合できないと業務停止などの行政処分が下ることがある。

設計観点と実装例

要件を実装可能な形に展開

　基本設計の工程では、広さと順序の2軸で定義したセキュリティー要件に「深さ」の軸を適用して、システムに実装可能な形にしていく。

＜深さ：対策を実装すべきレイヤーを決定する＞

　ここでいう深さとは、「アプリケーション」「ミドルウエア」「OS」「ハードウエア（サーバー）/ネットワーク」といったシステムのレイヤー構造をいう。この深さを踏まえて、各レイヤーまたはレイヤー横断で実装すべきセキュリティー要件を検討する。そのうえで開発コストや工数、期間、さらに各レイヤーで想定される脅威や、システム外での対策状況などを踏まえて、選択と集中の観点で実装対象とするセキュリティー要件を決定する。

　万全を期すためには、あらゆる対策を全てのレイヤーで実装するのが理想だ。だがそれでは対策の重複や煩雑化を生み、実装・運用コストの肥大や性能劣化につながる恐れがある。企画・構想工程で検討したリスク対応方針を考慮して、要件を絞り込む姿勢が肝要だ。

　検討結果を基に「セキュリティー基本設計書」を作成する（または通常のシステム基本設計書に組み込む）。この段階で実装方針が決まらなかった要件や検討課題は、一覧にして詳細設計以降へ引き継ぐこととし、所管部門の承認のもと工程を完了する。

　FinTechサービスでは、冒頭で示したように複数の外部サービスが連携するケースが少なくない。FinTechサービス企業は、金融機関が保有するデータやシステムの機能を、APIを介して直接またはAPI連携サービス事業者経由で自社のシステムに取り込む。これらのシステムは多くの場合クラウド環境にあり、そこでデータを加工して自社が獲得した顧客にサービスとして提供する。

　こうしたサービスを安全に提供するには、様々なステークホルダー連携を意識したセキュリティー要件の整理が必要となる。いま、以下のような仕組みを例に取る。FinTech企業のモバイルアプリを外部認証アカウントと連携させてユーザー認証し、資産運用サービスへログインさせる。資産購入時にはAPI経由で金融機関のバックエンドシステムが保有する個人金融資産情報にアクセスして与信判断し、決済代行システムと連動した決済処理結果をユーザーに返す。

　この場合、大まかには「1.ユースケースの整理」、「2.処理シーケンスの可視化」、「3.アクター間での仕様検討」、「4.アクター内での設計・実装」という流れで検討を進める。

　1.では、金融機関が保有する個人の金融資産情報資産と連携して処理を行う業務のユースケースを定義する。2.では、各アクター（モバイルアプリ、認証基盤、利用者ページ、金融システムなど）が関連する一連の処理シーケンスを可視化し、シーケンス全体で求めるセキュリティー要求レベルを把握する。

　3.では、アクター同士の各処理接点で必要なセキュリティー仕様を洗い出し、各者でどう機能分担して実装していくのかをすり合わせる。4.では、セキュリティー仕様をアプリ、OS、ネットワークなどに分解してアクターごとに実装する。

チェックリストを活用する

　セキュリティー要件を抜け漏れなく設計に落とし込むためには、チェックリストの活用が効果的だ。上流工程だけでなく、後続の詳細設計時のレビューやテスト工程でも活用できる。

　例えば要件定義では、対策の広さ（アカウント管理、認証などの対象領域）と順序（特定、防御など）でセキュリティー要件を分類し、漏れなく検討できるようチェックリスト形式で一覧化する。基本設計では、これをアプリケーション、ミドルウエア、OSなどレイヤーごとに分解して、それぞれに表を作る。

　チェックリスト形式で要件を整理したら、「工程」「設定値」「リスク」「優先度」「代替策」について検討する。これらは、後続工程で特殊な業務要件などによって追加要求されるセキュリティー品質、データやシステム環境における精査や条件、工数・コスト、期間、開発者のスキルといった開発・運用時の制約条件に応じてセキュリティー要件を調整する際の判断材料となる。

（a）工程：要件を検討してドキュメントに反映する工程を宣言する。例えば、「アクセス権限を付与するユーザーの範囲は企画・構想、アカウントの管理ポリシーは要件定義、アカウントのモニタリング方法は基本設計」などとする。

（b）設定値：「アカウントの有効期限は90日、パスワードは英数字と記号を含む8文字以上」などと設定推奨値を記載する。例えば、PCI DSSやCIS Benchmarks、Microsoftの推奨設定などに規定された推奨値が参考になる。

（c）リスク：「コーディング時に標準ライブラリーを利用しない場合、一部のユーザー入力値のエスケープ処理においてSQLインジェクションの脆弱性が残る」といった具合に、実装しない場合の影響を記載する。

（d）優先度：リスクや予算、納期、要員の工数・スキルなどを考慮して「必須」「推奨」「任意」を設定する。例えば、システムの重要度が高くても納期を優先して実装は「必須」の要件のみとし、「推奨」「任意」はシステム稼働後に要件追加の是非を検討、などとする。

（e）代替策：要件をシステムに実装するか、運用でカバーするか、などを検討する。例えば、アカウント棚卸機能は実装せず、担当者が週次で不要なアカウント・権限を目視で確認、などとする。

　これらの項目でチェックできるよう、さらに「判定」「備考」を追加する。

（f）判定：事前にセキュリティー要件の設計方針に関する「合格基準」を定義しておき、担当者と開発責任者がそれに基づいて「OK」「NG」「対象外」などと判断する。

（g）備考：判定の根拠や、工程完了判定時の判断結果を記載する。後続工程やリリース後に必要な対応が明確になり、セキュリティー要件を詳細設計以降で確実に実装していくためのトレーサビリティーも確保できる。

※「日経FinTech　2020年6月号」より、一部加筆の上、転載。　　　

　https://info.nikkeibp.co.jp/nft/sales/

　日経BPの了承を得て転載／無断転載・複製を禁じます。