フィンテックのサイバーセキュリティ：オープンソースを安全に活用する方法

フィンテック企業にとってサイバーセキュリティが重要なのはなぜでしょうか？

金銭のやり取りは、手っ取り早く利益を得ようとするハッカーにとって格好の標的です。そのため、従来型の銀行には厳格なサイバーセキュリティ規制が適用されています。一方、金融テクノロジー（フィンテック）企業は銀行ほど厳しく規制されておらず、アプリケーションを完全に保護する明確な要件がない場合は特に、セキュリティプロセスにおける重要な手順を省略してしまうことも少なくありません。

しかし、フィンテック企業がサイバーセキュリティを最優先事項として捉えるべき理由はいくつかあります。

保存するデータの種類

フィンテック企業は銀行と同じ種類の金融データを扱うため、攻撃者にとって魅力的な標的です。こうした機密データには、口座情報、口座残高、キャッシュフローや予算に関する情報、連絡先情報などが含まれます。

特にAI/MLプロジェクトでのデータマイニングにおいて、こうしたデータは価値が高いため、フィンテック企業には可能な限り詳細で有用なデータを保存する動機があります。しかし、大量のデータを保存すれば、攻撃者にとっての価値も高まり、標的になりやすくなるというトレードオフがあります。

侵害によるコスト

従来型の銀行にとって、侵害によるコストには直接的な費用だけでなく、評判の失墜や罰金などの間接的な費用も含まれます。1度の侵害で、何千人もの顧客を失う可能性もあります。フィンテック企業も銀行と同じ種類のデータを扱うため、侵害によって同様の悪影響を受ける可能性があります。特にフィンテックのスタートアップや急成長中の企業では、顧客の信頼を失い、評判が損なわれることが、侵害による最も大きな損失となる場合があります。また、罰金や訴訟などの法的措置につながる可能性もあります。

コンプライアンス

フィンテック企業には、顧客が所在する地域の規制に加え、顧客確認（KYC）に関する要件を遵守する義務があります。こうした規制には、次のものがあります。

• EU：一般データ保護規則（GDPR）は、組織がEU域外にある場合も含め、EU居住者の個人データの処理を規制します。電子識別およびトラストサービス（eIDAS）は、国境を越えたデジタル取引を規定し、フィンテック企業、顧客組織、規制当局、エンドユーザー向けに統一された枠組みを提供します。決済サービス指令（PSD2）は、電子決済のセキュリティを定めています。PSD2はGDPRと重複する部分が多いため、コンプライアンスを確保するには専門家への相談が必要になる場合があります。

• 米国：主要なクレジットカードのデータの収集、処理、利用を規制するペイメントカード業界データセキュリティ基準（PCI DSS）。

• カリフォルニア州：カリフォルニア州消費者プライバシー法（CCPA）はGDPRに似ていますが、法律用語の定義などにいくつかの違いがあります。フィンテックのデータアグリゲーターであるYodleeは、データの収集および利用方法がCCPAに違反したとされ、集団訴訟に直面しました。

フィンテック企業がサイバーセキュリティで直面する課題とは？

フィンテック企業にとってサイバーセキュリティは最優先事項であるべきですが、アプリケーションを適切に保護するには多くの障壁があります。従来、サイバーセキュリティは、パスワード、暗号化、多要素認証、安全なロジックなどによって最終製品を保護することに重点を置いてきました。セキュリティの責任は、IT運用チームやセキュリティチームが担っていました。アプリケーションのテストは主に本番環境へのリリース後に行われていたため、多くの組織がリスクにさらされていました。バグや脆弱性が発見されると、セキュリティチームはアプリケーションの開発者までさかのぼって対応する必要がありました。

現在では多くの企業が、リリース前にもセキュリティテストを取り入れています。しかし、予定外の問題が発生してリリースサイクルが長引く可能性があります。発見した数十、あるいは数百もの脆弱性にどう対処すればよいでしょうか。脆弱性の修正には、基盤となるソフトウェアコンポーネントの大幅な書き換えが必要となり、その後、再検証や再テストを行わなければならない場合があります。さらに、これがセキュリティチームと開発者の間に摩擦を生むこともあります。フィンテック製品をより早く市場に投入するために、開発者が安全でないソフトウェアをリリースしてしまうこともありますが、ソフトウェア開発ライフサイクル（SDLC）の後半で問題を修正するには、多大なコストがかかります。

つまり、従来のテスト手法は時代遅れになっています。脆弱性の種類は変化し、ソフトウェアの開発・提供方法も変わりました。迅速な提供が求められる市場では、主流のアプリケーション開発にアジャイル手法が使われています。より現代的なDevOpsアプローチでは、大規模な一枚岩のリリースを短いスプリントに分割し、1日に複数回新機能をリリースして、迅速に反復し、可能な限り自動化を取り入れます。アジャイル手法を採用する組織では、クラウド以前の時代に設計された従来型のアプリケーションセキュリティツールが、迅速かつ安全なデプロイの妨げになることがあります。

フィンテック企業にとってオープンソースにはどのようなリスクがありますか？

オープンソースのライブラリやパッケージの普及は、フィンテックのサイバーセキュリティにさらなる課題をもたらします。クラウドアプリケーションは通常、多数のオープンソースライブラリやサービスを統合しています。これにより、開発者は他者がすでに構築したものを活用できますが、攻撃者にネットワークへ侵入する隙を与えることにもなります。

こうしたオープンソースのアプリケーションには脆弱性が含まれている場合があり、本番環境に持ち込まれる可能性があります。ビルドプロセスの終盤や本番環境で脆弱性が発見されると、プロジェクトの遅延につながります。

推移的な依存関係（依存関係の依存関係）は、複雑な依存関係ツリーを形成するため、特有のリスクがあります。そのため、アプリケーションが脆弱性を含むパッケージを呼び出していることを見落としやすくなります。オープンソースの利用が拡大するなか、現代のフィンテックアプリケーションでは、自社開発のコードだけでなく、攻撃対象領域も広がっています。

フィンテックにDevSecOps文化を取り入れるには？

現代のソフトウェア開発では、セキュリティは一度限りの解決策ではなく、プロセスの一部である必要があります。セキュリティテストツール、侵入テスト、監査を活用し、開発ライフサイクル全体にセキュリティを組み込むべきです。

DevSecOpsとして知られるこの新しいセキュリティアプローチは、DevOpsを拡張し、開発、セキュリティ、運用の各チームがセキュリティに対する責任を共有します。セキュリティチームとDevOpsチームは初期段階から連携し、CI/CDパイプラインにセキュリティを組み込みます。脅威モデリングも早期から頻繁に実施します。開発者はプロセス全体を通じて、sソフトウェア構成 分析 （SCA）を活用し、オープンソースコンポーネントを監視します。

本番環境に投入される機能やアプリケーションは、共同作業の成果となります。開発チームは、開発プロセスの初期段階からセキュリティが組み込まれていると理解できるため、セキュリティチームが事後に開発チームへ対応を求める必要はありません。DevOpsプロセスにセキュリティを統合することで、開発者がセキュリティに責任を持てるようになります。脆弱性やバグを早期に発見できるため、DevSecOpsは最終的に、コストを抑えながら、より安全なソフトウェアを迅速に提供できるようにします。

DevOpsからDevSecOpsへの移行は、開発者だけの責任ではありません。セキュリティチームは計画プロセスを監督し、既存のワークフローをできるだけ妨げずにセキュリティを適用することに注力すべきです。

セキュア・バイ・デザインの考え方を取り入れる

DevSecOpsは、設計段階から安全なソフトウェアの実現を目指します。その取り組みは開発の初期段階から始まり、バッファオーバーフローや例外処理の不備など、コードの問題を未然に防ぐことに重点を置く、ソフトウェアセキュリティを取り入れます。

バグを発見して修正するツールや手順を整備し、開発の初期段階を適切に進めることが重要です。オープンソースのライブラリやパッケージの依存関係も重要な領域です。複雑化すると把握しにくくなり、アプリケーションの脆弱性が見えづらくなる可能性があります。

フィードバックのサイクルを短くすればバグの発生を抑えられます。また、セキュア・バイ・デザインの原則に基づいてオープンソースライブラリを選ぶことも重要です。

シフトレフトの原則を取り入れる

セキュア・バイ・デザインの重要な要素の1つがシフトレフトセキュリティです。アプリケーションのセキュリティ対策を初期段階から組み込みます。シフトレフトによって、開発者は既存のワークフローにセキュリティを統合でき、セキュリティチームは開発者を支援し、監督できます。まずセキュリティポリシーを定め、ソフトウェアの作成プロセスを評価して、より早い段階でテストするために実施できる小さな手順を見つけます。セキュリティを自動化し、プロセス全体をチームが常に把握できるようにすることが重要です。

安全なSDLCを構築する

セキュアSDLCは、ソフトウェア開発におけるDevSecOpsアプローチを補完します。DevSecOpsはアプリケーションセキュリティに対する責任の共有に重点を置き、セキュアSDLCは設計・構築プロセスへのセキュリティの組み込みに重点を置きます。

標準的なSDLCを保護するには、まず開発チームの意識を変えることが大切です。機能だけでなく、プロジェクト全体を通じたセキュリティにも注目する必要があります。従来のチェックをなくすのではなく、ソフトウェアを本番環境にリリースしてからさかのぼって問題に対処するのではなく、初期段階から潜在的な問題に対応することが目標です。

セキュリティの取り組みを主導するのは開発チームです。つまり、ソフトウェアを書く領域の専門家が問題を修正します。大変な作業に思えるかもしれませんが、セキュアSDLC環境では大部分が自動化されます。その結果、より低コストで、本番環境におけるアプリケーションの安全性を高められます。

Snykがフィンテックのサイバーセキュリティを支援する方法

Snyk Open Sourceは、IDEまたはCLIでコーディングしている間に依存関係の脆弱性を検出するSCAツールです。開発者に使いやすいこのツールは、マージ前にプルリクエストをスキャンし、脆弱性がビルドプロセスを通過するのを防止できます。Snykを使えば、CI/CD全体でテストを自動化でき、既知または新たに発見された脆弱性へのアプリケーションの露出を継続的に検査できます。そのほか、継続的な監視、カスタマイズ可能なセキュリティルール、自動化されたライセンスコンプライアンス管理などの機能も備えています。

機密性の高い個人情報を扱うフィンテック企業として、Revolutは特定の基準を遵守する必要があります。Snykの導入により、同社は中核インフラを保護し、PCI準拠をはじめとする要件を満たせるようになりました。

「私たちは年間を通じて監査を受けています。Snykを使うことで、オープンソースのパイプラインを保護できていると言えます」とEvangelos Deirmentzoglou氏は語ります。「つまり、セキュリティリスクの改善だけでなく、コンプライアンスへの取り組みも支援しているのです。」

RevolutがSnykを活用してサイバーセキュリティを強化し、規制基準への準拠を維持した方法をご覧ください。

フィンテックでオープンソースコンポーネントを活用する方法について詳しく知りたい方は、オンデマンドウェビナーをご覧ください。フィンテックでオープンソースコンポーネントを活用するためのベストプラクティスと注意点

フィンテックのサイバーセキュリティに関するよくある質問