非金融業が金融系サービスを始める際に踏まえるべきセキュリティーのポイント｜他業界より高い要求水準、基準・ガイドラインが有用

　デジタル技術の普及に伴い、一般事業者が新たに金融系サービスを提供するケースが増えている。だが金融業界は慣習が異なり、様々な規制も存在しているため、参入した企業が戸惑うケースもみられる。特にセキュリティーに関しては他業界よりも要求水準が高く、必要に応じて金融機関とやり取りしつつ態勢を整備する必要がある。

はじめに

　金融機関が提供する様々な金融系サービスやサービスを支える基盤が、社会における重要なインフラであることは言うまでもない。当然、高いレベルの安全管理やセキュリティーが求められる。

　一方でFinTechの普及に伴い、決済や資金移動などの金融系サービスに乗り出す非金融業界の事業者が増えている。今後も参入が相次ぐとみられる。

　だが、一般の事業者が金融系サービスを手掛けるのは必ずしも容易ではない。金融業界特有の複雑な制度や慣行が存在するほか、サービスの仕組みや内容も複雑化しつつある。

　とりわけ大切なのは、金融系サービスに必要な安全管理とセキュリティー（以下、両者を区別せずにセキュリティーと呼ぶ）を実現するための仕組みや体制を整備し運用することだ。本稿では金融系サービスを提供する計画や構想を持つ一般事業者に向けて、セキュリティーを実現する上で踏まえるべきポイントについて解説する。既にサービスを提供している、あるいはサービス事業者向けにソリューションを提供している方も再チェックの観点からご覧いただければ幸いである。

　セキュリティー関連では、個人情報保護に関するガイドラインや、IPA（情報処理推進機構）が勧告・推奨するセキュリティー対策など、一般的な基準類が既に存在している。これらを踏まえている前提で、金融業界で特に留意すべき点を中心に取り上げる。

高レベルのセキュリティーを実現

　一般事業者が金融系サービスを始めるに当たり、まず留意する必要があるのは「金融業界に求められるセキュリティーレベルは、他業界よりも高い」という点である。前述したように、金融は社会における重要なインフラであり、その機能に支障が生じると経済活動が阻害されるおそれがある。このため、金融は他の業界に比べ、政府による規制の密度が濃いといえる。

　金融庁が長年にわたり監督行政を担ってきた結果、金融業界のセキュリティーは他業界よりも高いレベルで実現されている。実際、金融業界は2014年に、「ISAC（Information Sharing and Analysis Center）」を医療やエネルギーなどを含む重要インフラを担う業界の中でいち早く構築している。ISACは脅威情報を収集・分析・共有する組織だ。

 企業におけるセキュリティー対策の司令塔であるCISO（最高情報セキュリティー責任者）に関しても、金融業界は他の業界よりも置いている企業が多いことが分かる。日本情報システムユーザー協会（JUAS）の「企業IT動向調査2019」によると、CISOを設置済みと回答した金融業は43.6％で、全体平均の20.4％を大きく上回っている。

様々な指針・ガイドラインが存在

　金融業が高レベルのセキュリティーを維持するための下支えとなってるのが、様々な指針やガイドラインだ。金融系サービスに乗り出す事業者は、これらを念頭に置いてセキュリティー態勢を整備していくのが望ましい。

　指針・ガイドラインは金融庁のほか、金融情報システムセンター（FISC）などが公表している。主なものを見ていく。

　セキュリティーに関して参照すべきものとしては「監督指針・事務ガイドライン」と「金融分野における個人情報保護に関するガイドラインの安全管理措置等についての実務指針（以下、実務指針）」がある。

　監督指針と事務ガイドラインはともに、監督行政を担当する職員向けの手引書だ。監督事務の基本的な考え方や監督上の評価項目、事務処理上の留意点について、従来の事務ガイドラインの内容を踏まえて体系的に整理したものが監督指針である。金融機関や一般事業者向けに書かれたものではなく、内容も具体的ではないが、金融機関に求めるセキュリティーや委託先管理に関する監督行政としての考え方を理解する一助となる。

　一方、実務指針は個人情報保護委員会と金融庁の共管ガイドラインだ。「個人情報保護に関するガイドライン」に対し、金融分野で実現すべき安全管理措置についてより具体的に記載している。詳細は、金融庁Webサイトの「法令・指針等」や「金融分野における個人情報保護について」を参照してほしい。それぞれQ＆Aも掲載しており、内容を解釈する際の参考になる。

　FISCは金融庁の外郭団体で、金融機関やIT企業などで構成される。金融業界における自主基準の策定や調査研究などを手掛けており、その成果を基準や手引書、チェックリストなどとして刊行している。多くはFISCの非会員でも購入できる。

　セキュリティーに関して最も多用されているのは、「金融機関等コンピュータシステムの安全対策基準・解説書」だ。金融システムの導入や運用に関するガイドラインを示したもので、「FISC安全対策基準」「FISC安対」とも呼ばれる。

　ここでいう金融機関等は「銀行等の預金取扱金融機関、信託会社、保険会社、証券会社、クレジット会社など」を指す。「電子決済等代行業者などのFin Tech企業などを除く」としている。

　この定義を見ると、金融系サービスを手掛ける一般事業者の多くはFISC安全対策基準の適用外となる。それでも内容はセキュリティーに関わる考え方から具体的な対策の例示まで幅広く、金融機関における一般的なセキュリティー水準がどのようなものかを理解する上で有用であるといえる。直接の適用対象でない企業も参照しておくことが望ましい。

　FISC安全対策基準は、一般事業者が見落としがちな安全管理措置についても広く留意している。例えば、コンティンジェンシープランに関わる基準項目で「集中豪雨、降雪等による交通遮断、あるいは感染症のパンデミック発生などから生じる職員不在等の不測の事態についても、要員確保の観点から考慮することが必要である」などと記載しており、主たる脅威への対策を検討するに当たり、抜けや漏れが生じにくい。一般事業者の間で広く知られるISO/IEC27001などは具体的な危機事象に触れていない。

　FISC安全対策基準は300近い項目から成り、「基礎基準」と「付加基準」に大別される。基礎基準は、金融機関等が業法などに基づいて顧客に商品・サービスを提供するために利用する全てのシステムへの適用を想定したもの。付加基準は、その中で特に重要なシステムへの適用を想定したものだ。顧客に商品・サービスを提供する目的ではないシステムについては、定めていない。

　各基準における個々の対策は「必須対策」と「その他の対策」に分かれる。リスクの種類や大きさに応じて、基準や対策を適宜選択することが基本となる。参考になる例示が含まれる基準や対策も少なくない。

指針・ガイドラインへの向き合い方

　ここまで説明したセキュリティーに関する指針やガイドラインは基本的に金融機関を対象にしている。金融系サービスを扱う一般事業者は、これらに対してどのように向き合うべきか。

　分かりやすいのは、事業者が銀行免許の取得などによって、金融機関として新たに金融系サービスを提供するようなケースだ。この場合は既存の金融機関と同様、金融庁やFISCなどの指針・ガイドラインに準拠する必要がある。

　ただ、このようなケースは実際には少ないとみられる。大半は、サービスの提供主体は一般事業者（非金融機関）であり、資金移動業者などとして利用者に直接または金融機関を通じてサービスを提供する形になると考えられる。後者は例えば金融機関のポータルやスマートフォンアプリと連携する形を指す。

　この場合、特にFISC安全対策基準に関しては、一般事業者が金融機関の「委託先等」に当たるかどうかで対応が分かれる。ここでいう委託先等には狭義の委託契約先だけでなく、金融機関が利用するサービスの提供主体なども含まれる。

　委託先等に該当する場合は安全対策基準の適用対象となり、金融機関はその事業者に対する管理責任を負う。このため、金融機関は委託先等を適切に選ぶとともに、事業者がセキュリティーなどに関して適切な状態かどうかを確認する必要がある。委託先等に当たる事業者は安全対策基準などの指針・ガイドラインを踏まえた上で、必要なセキュリティー態勢の準備・構築に向けて金融機関とあらかじめ対話しておくことが大切になる。

　例えば、金融機関やその委託先等でセキュリティーインシデントが発生した場合、金融機関は速やかに当局などに報告する必要がある。そのためには、委託先等が金融機関に対して、即座にインシデント報告を作成・通知できる態勢づくりが欠かせない。こうした点について、具体的な報告内容や報告手段などを金融機関と調整しておくことが大切になる。

　金融機関の従業員が委託先等のサービスを利用するケースもある。この場合、委託先等は金融機関に対し、当該サービスに付随して重要な操作などに関するアクセスログのモニタリング機能を提供することが望ましい。端末やネットワーク上で操作内容や電文などを収集・モニタリングするのは一般に非効率であり、従業員のアクセスログをモニタリングする仕組みがサービスとともに提供される意義は大きい。

「ゼロリスク志向」は不要

　金融系サービスを扱う一般事業者が金融機関の委託先等に当たらない場合も、独自の目線や尺度に頼るのでなく、安全対策基準などの指針・ガイドラインを踏まえてセキュリティー体制を準備・構築するよう心がけておきたい。

　事業者が提供するサービスに金融機関等の統制が部分的に及ぶ場合、金融機関等の責務の生じる範囲で安全対策基準などが部分的に適用される可能性がある。安全対策基準の適用外であっても金融系サービスである以上、金融機関と全く関係しないというケースは少ないと考えられる。

　金銭などを取り扱う金融業界は、以前から犯罪者などに狙われやすい素地があったため、他の業界よりも利用者のなりすまし防止などの対策を厳しく施している。だからといって、全てのリスクに対して1つひとつ対応しようとすると、事業者の負担が大きくなる。

　金融業界では、リスクの大きさに応じて選択的に対応する「リスクベースアプローチ」の採用が進んでいる。小さいリスクにまで対策を施すゼロリスク志向を採る必要はない。

　その上で、規定類や体制の整備、セキュリティー機能の設計・実装・診断・運用、リスク評価や監査の実施といったセキュリティー対策を実施する際に、どのようなリスクに対してどのような理由で対策を選定したか、どのような残存リスクを受容するのか、などについて金融機関などに説明可能な状態にしておくことが望ましい。具体的には、リスクの評価・分析を行う際に、外部に提示できる形で記録を残すことになる。

サービスリスク分析も有用

　一般事業者が金融系サービスを提供する上で必要なセキュリティー対策を検討する際は、「サービスリスク分析」も役立つと考えられる。最後に、この点について触れておきたい。

　サービスリスク分析は、連携するサービス全体を見渡し、どこにリスクが潜んでいるかについて不正な手口を考慮した攻撃シナリオを基に検討する手法を指す。NRIセキュアブログ「QRコード決済に迫る攻撃者 セキュリティー対策の要諦」ではQRコード決済サービスのセキュリティー対策として紹介したが、比較的新しい形態のデジタルサービス全般に有効な手法とみなせる。

　新たなFinTech関連サービスには、金銭やポイントなどをやり取りする、プライバシー性の高い決済関連情報を扱うといった具合に、犯罪者の気持ちを強くかき立てる可能性のある要素が少なくない。加えて、サービスを提供する事業者と金融機関、他の事業者などと複雑な利用者認証やポイント交換などの連携を実施するため、セキュリティー上の考慮漏れが発生しやすい。この点を突いて、様々な形で不正な処理がなされるおそれもある。

　サービスリスク分析を実施すれば、このようなセキュリティーに関する漏れや抜けの防止を期待できる。ただ、この作業を開発工程の途中で実施すると作業の手戻りが生じる可能性があるため、開発工程の上流段階で行うことが望ましい。

　開発工程は各社各様なので、どの段階でサービスリスク分析を実施するのが適切かどうかは個別に判断する必要がある。例えば機能要件が定まった時点で実施すれば、サービスを構成するそれぞれの機能や機能同士の関係に基づいて、不正な手口が成り立つかどうかを分析できる。

　規模が比較的大きい事業者であれば、事業部門と統制部門を分けて、事業部門が実施したサービスリスク分析を統制部門がチェックする形を採るのが望ましい。小規模な事業者のようにこの形を実現するのが困難な場合は、同一部門に統制を担う担当者を置く、各
種管理者の間で相互にけん制を働かせる、といった施策が考えられる。

　サービスリスク分析は比較的新しいリスク管理手法であり、現時点で手順を具体的に規定した基準やガイドラインなどは存在しない。機能要件に基づいて様々な不正の手口を想定したり、世間でこれまでに起きた主なデジタルリスクの顕在化事例を踏まえたりすることを通じて、サービスの利便性やコストとリスクの低減のバランスを図る。同時に、リスク管理の状況を説明可能な状態にしていく──。このような姿勢で臨むことが大切になる。

　金融分野では、以前から扱っている現金や金融商品に加えて、ポイントなど金銭的価値のあるものの取り扱いが増えている。それらの不正取得や利用に関するリスク顕在化事例は国内外で散見されている。こうした事例は自社のサービスと全く同じ形態ではないとしても、同様の手口が成立しないかどうかを確かめる上で有用である。これらの情報を適宜収集し、参考にすることが望ましい。