2024年末から2025年にかけて、金融機関を標的としたサイバー攻撃が急増した。DDoS攻撃による決済サービスの停止、ランサムウェアによる顧客情報の漏洩リスク、そしてサプライチェーンを経由した侵入 — 脅威の質と量は明らかに次のステージに入っている。金融庁は2024年10月に「金融分野におけるサイバーセキュリティに関するガイドライン」を公表し、176項目の対策事項を明示した。FISC（金融情報システムセンター）は2025年3月に安全対策基準の第13版を公表し、全体の約3割を改訂した。本記事では、金融情報システム開発に20年以上携わってきたSESエンジニアの視点から、FISC基準とゼロトラスト・アーキテクチャを統合した実装戦略を、現場の知見を交えて解説する。
金融セキュリティを取り巻く2025年の脅威環境
サイバー攻撃の実態 — DDoS・ランサムウェア・データ侵害の急増
2024年末から2025年にかけて、日本の金融機関を取り巻くサイバー脅威は急速に深刻化した。警察庁の発表によると、2025年上半期のランサムウェア被害報告件数は116件で半期最多タイを記録し、高止まりの状況が続いている。業種別のセキュリティインシデント公表件数では、金融業は製造業、サービス業に次ぐ3位に位置しており、もはや「狙われにくい業種」ではなくなっている。
特に注目すべきは、2024年末から続いたDDoS攻撃の波だ。JAL、NTTドコモ、日本気象協会など国内の主要組織が標的となり、Webサービスの一時停止が相次いだ。金融機関も例外ではなく、損害保険ジャパンでは最大約1,750万件の顧客情報漏洩の可能性が報じられ、保険見直し本舗ではランサムウェア攻撃により約510万件の情報漏洩リスクが発生した。
現場で20年以上金融セキュリティに携わってきた実感として、攻撃の変化は「量」だけではない。攻撃の「精度」と「持続性」が格段に上がっている。かつてのDDoS攻撃は大量のトラフィックを短時間流すだけの単純なものが多かったが、現在はアプリケーション層を標的とした低帯域・高精度のL7攻撃や、複数の攻撃ベクトルを組み合わせたマルチベクトル攻撃が主流となっている。防御側は「量で弾く」だけでは対処しきれない時代に入った。
規制強化の三本柱 — 金融庁ガイドライン・FISC第13版・DORA
脅威環境の変化に呼応するように、規制面でも2024年から2025年にかけて大きな動きが3つあった。
第一の柱: 金融庁サイバーセキュリティガイドライン。2024年10月4日に公表されたこのガイドラインは、「サイバーセキュリティ管理態勢の構築」「リスクの特定」「攻撃の防御」「検知」「インシデント対応及び復旧」「サードパーティリスク管理」の6分野にわたり、合計176項目の対策事項を定めている。従来は業種ごとに分かれていた監督指針のセキュリティ関連項目を、業種横断の共通ガイドラインとして一本化した点が画期的だ。公表と同時に適用が開始され、経過措置がないことも大きな特徴である。
第二の柱: FISC安全対策基準第13版。2025年3月に公表された第13版は、前述の金融庁ガイドラインを反映し、全体の約3割が改訂された大規模な改版である。経済安全保障推進法への対応、AI利用における安全対策の新設、オペレーショナル・レジリエンスに関する解説の追加が主要な改訂ポイントとなっている。詳細は次章で解説する。
第三の柱: EU DORA（Digital Operational Resilience Act）。2025年1月17日にEU全加盟国で施行が開始されたDORAは、金融機関のICTリスク管理、インシデント報告、レジリエンステスト、サードパーティリスク管理、情報共有の5分野を包括的に規制する。「日本の金融機関には関係ない」と思われがちだが、EU圏の顧客にサービスを提供する金融機関やICTベンダーは適用対象となる。さらに重要なのは、GDPRがそうであったように、DORAが今後の国際的なセキュリティ規制の「テンプレート」となる可能性が高い点だ。金融庁のガイドラインにもDORAと共通する考え方が随所に見られ、日本の規制もこの方向に収斂していくだろう。
量子脅威という次の波 — PQC移行の準備
現在の脅威に対処するだけでは十分ではない。金融機関は「まだ来ていない脅威」にも備える必要がある。それが量子コンピュータによる暗号解読の脅威だ。
2024年8月、NIST（米国標準技術研究所）はPQC（Post-Quantum Cryptography: 耐量子計算機暗号）の標準を最終決定し、2025年3月には鍵交換アルゴリズムHQCの標準化も決定した。日本では、金融庁主導で「預金取扱金融機関の耐量子計算機暗号への対応に関する検討会」が開催され、2024年11月に報告書が公表されている。
量子脅威の本質は「Harvest Now, Decrypt Later（今収集し、後で復号する）」攻撃にある。現在の暗号通信を傍受・蓄積しておき、将来量子コンピュータが実用化された時点で復号するという手法だ。金融機関が扱うデータには、10年以上の保存が求められるものも多い。つまり、今日暗号化したデータが、10年後に丸裸になるリスクがすでに存在している。
日本における対応期限はまだ明確化されていないが、金融庁の検討会報告書（2024年11月公表）では2030年代半ばを目安に優先度の高いシステムでの対応を推奨している。金融機関にとっての実務的な準備としては、自社システムで使用している暗号アルゴリズムの棚卸し（暗号インベントリの作成）が第一歩となる。現場の感覚では、この棚卸し作業自体が相当な工数を要する。20年以上にわたって増改築を繰り返してきたシステムでは、どこでどの暗号アルゴリズムが使われているかを完全に把握すること自体が困難だからだ。
FISC安全対策基準第13版の要点と実装への落とし込み
第13版で何が変わったか — 第12版からの主要改訂ポイント
FISC安全対策基準は、金融情報システムのセキュリティに関する事実上の業界標準であり、金融庁の検査・監督でも参照される重要な基準体系だ。2025年3月に公表された第13版は、第12版（2024年3月公表）から約1年での改訂であり、改訂規模の大きさがこの分野の変化の速さを物語っている。
第13版の主要な改訂ポイントは以下の5つに集約される。
1. 金融庁サイバーセキュリティガイドラインへの対応。2024年10月に公表されたガイドラインの176項目を、FISC基準の各項目に紐づける形で反映した。これにより、FISC基準への準拠がそのまま金融庁ガイドラインへの対応にもなるという整合性が確保された。
2. 経済安全保障推進法への対応。「特定社会基盤事業者」に指定された金融機関等に求められる対応を基準項目に取り込んだ。サプライチェーンリスクの観点から、外部委託先やソフトウェア調達における安全性確認が強化されている。
3. AI利用における安全対策の新設。生成AIの急速な普及を受け、AI利用に関する安全対策基準が新たに設けられた。AIモデルの入出力データの管理、ハルシネーション（事実と異なる出力）への対処、学習データの品質管理などが対策項目として明示されている。
4. オペレーショナル・レジリエンスの強化。金融庁が2023年4月に公表した「オペレーショナル・レジリエンス確保に向けた基本的な考え方」を受け、「重要な業務」の特定と、その業務が許容できる中断の範囲（インパクト・トレランス）の設定に関する解説が追加された。
5. 最近のシステム障害・サイバーセキュリティ事例の反映。金融庁の「金融分野におけるITレジリエンスに関する分析レポート」（2025年6月公表）によると、2024年度のシステム障害は「ソフトウェア障害」と「管理面・人的要因」が全体の約7割を占めている。第13版ではこうした実態を踏まえた対策が強化されている。
FISC基準の「技術基準」「運用基準」「設備基準」を実装に変換する
FISC安全対策基準は「技術基準」「運用基準」「設備基準」の三本柱で構成されている。基準書には「何をすべきか」が記載されているが、「どう実装するか」は各金融機関の判断に委ねられている。この「行間を読む」作業こそが、20年の経験が問われる領域だ。
技術基準の実装変換。技術基準はアクセス制御、暗号化、ログ管理、脆弱性管理などの技術的対策を定める。例えば「アクセス制御の適切な実施」という基準を実装に落とし込む場合、具体的にはRBAC（Role-Based Access Control）の設計、特権アカウントのPAM（Privileged Access Management）による管理、多要素認証の適用範囲の決定、そしてセッション管理のタイムアウト設定まで、実装上の判断が数十項目にわたる。基準書の1項目が、実装レベルでは設計書の数ページに展開されるのが通常だ。
運用基準の実装変換。運用基準はインシデント対応、変更管理、バックアップ、監視などの運用プロセスを定める。ここで重要なのは、運用基準を「手順書」ではなく「自動化の設計図」として読むことだ。現代のセキュリティ運用では、インシデント検知からアラート通知、初動対応の一部までをSOAR（Security Orchestration, Automation and Response）で自動化することが求められる。手作業に依存した運用体制では、24時間365日の監視を維持するコストが膨大になる。
設備基準の実装変換。設備基準はデータセンター、ネットワーク、電源設備などの物理的対策を定める。クラウド環境ではこの領域の大部分がクラウドベンダーの責任範囲となるが、責任分界点（Shared Responsibility Model）の明確化が不可欠だ。AWSの場合、「AWS FISC安全対策基準対応リファレンス」でベンダー側の対応状況が確認できるが、利用者側の責任範囲 — 仮想ネットワークの設計、セキュリティグループの設定、暗号鍵の管理 — については自社で設計・実装する必要がある。
【実務Tips】FISC監査で指摘されやすいポイントと対処法
20年以上の金融セキュリティ実務を通じて、FISC監査で繰り返し指摘される「定番」のポイントがいくつかある。事前に押さえておくことで、監査対応の負荷を大幅に軽減できる。
指摘ポイント1: ログトレーサビリティの不備。「ログは取っているが、追跡に使えない」という状態が最も多い。具体的には、アプリケーションログ、OSログ、ネットワークログの相関分析ができない、ログのタイムスタンプがシステム間で同期されていない、ログの保存期間が基準を満たしていない、といった問題だ。対処法としては、ログ基盤の統合（SIEM導入）、NTPによる時刻同期の徹底、ログ保存ポリシーの明文化と自動アーカイブの実装が有効である。
指摘ポイント2: 外部委託先管理の形骸化。SES活用やクラウドサービス利用が当たり前になった現在、外部委託先の管理が「年1回のチェックシート回収」で済まされているケースが散見される。第13版では経済安全保障推進法を反映してサプライチェーンリスク管理が強化されており、委託先のセキュリティ評価は実効性が求められる。対処法として、委託先との定期的なセキュリティレビュー会議の実施、委託先のSOC2レポートや第三者評価の確認、委託先変更時のリスク再評価プロセスの整備を推奨する。
指摘ポイント3: クラウド責任分界点の不明確さ。「クラウドベンダーが対応している」という曖昧な認識で、利用者側の責任範囲が手つかずになっているケースだ。AWSやAzureの共有責任モデルは「インフラの物理的セキュリティはベンダー、その上のすべては利用者」という明確な線引きがあるが、この線引きをFISC基準の各項目に紐づけて整理している金融機関は意外に少ない。対処法として、FISC基準の各項目に対する責任分担マトリクス（RACI図）を作成し、クラウドベンダー・SIer・自社のそれぞれの責任範囲を可視化することが有効だ。
ゼロトラスト・アーキテクチャの金融機関への実装
なぜ境界型防御では不十分なのか — 金融庁調査報告書が示すもの
金融庁が2021年に公表した「ゼロトラストの現状調査と事例分析に関する調査報告書」（PwCあらた有限責任監査法人作成）は、境界型防御の限界を明確に指摘した文書として、現在もなおゼロトラスト導入の出発点となっている。
境界型防御（Perimeter Security）は、「社内ネットワークは安全、社外は危険」という前提に基づき、ファイアウォールやVPNで境界線を引く伝統的なセキュリティモデルだ。しかし、この前提は以下の3つの構造変化によって崩壊している。
第一に、クラウド移行の進展。前回の記事（銀行システムのセキュリティ設計手法と最新ベストプラクティス）でも触れたとおり、金融機関のシステムはオンプレミスからクラウドへの移行が進んでいる。データと業務がクラウド上に分散した環境では、「社内」と「社外」の境界自体が曖昧になる。
第二に、リモートワークの常態化。コロナ禍を経て、金融機関でも在宅勤務や外部拠点からのアクセスが定常化した。VPN集中によるパフォーマンス低下やVPN機器自体の脆弱性が新たなリスクとして顕在化している。
第三に、攻撃手法の高度化。前述のとおり、サプライチェーン攻撃や内部犯行によるデータ侵害は、境界の「内側」で発生する。境界型防御では、一度境界を突破した攻撃者がネットワーク内を自由に横移動（ラテラルムーブメント）できてしまう。
金融庁の報告書は、これらの課題に対する解としてゼロトラスト・アーキテクチャの導入を推奨している。ただし、報告書が強調しているのは「ゼロトラストは製品ではなく、考え方（アーキテクチャ）である」という点だ。特定のベンダー製品を導入すれば完了するものではなく、組織全体のセキュリティ設計を根本から見直す取り組みが求められる。
ゼロトラストの5つの柱と金融機関での実装
ゼロトラスト・アーキテクチャの実装は、NIST SP 800-207で定義された原則に基づき、以下の5つの柱で構成される。金融機関での実装における具体的なポイントを整理する。
柱1: アイデンティティ。すべてのアクセスは、ユーザーとデバイスの両方で認証・認可する。金融機関では、行員のアクセスだけでなく、サービスアカウント（システム間連携用のアカウント）の管理が盲点になりやすい。勘定系と情報系の連携に使われるサービスアカウントが長年パスワードを変更されないまま運用されているケースは、実際のプロジェクトで頻繁に遭遇する。IAM（Identity and Access Management）の統合管理基盤を構築し、人的アカウントとサービスアカウントの双方を一元管理することが出発点となる。
柱2: デバイス。アクセス元のデバイスの信頼性を継続的に検証する。デバイス証明書の発行・管理、EDR（Endpoint Detection and Response）の導入、OSパッチの適用状況の常時監視が基本的な実装要素だ。金融機関では端末管理が厳格な反面、VDI（仮想デスクトップ）環境のセキュリティ設定が画一的で、業務特性に応じた細分化ができていないケースがある。
柱3: ネットワーク。ネットワークレベルでのアクセス制御をマイクロセグメンテーションで実現する。次節で詳述する。
柱4: アプリケーション・ワークロード。アプリケーションへのアクセスをAPI Gateway経由で一元管理し、認証・認可・レート制限を適用する。金融機関では、レガシーなWebアプリケーションがSSO（Single Sign-On）に対応していないケースが多く、リバースプロキシ型のSSOアダプターを前段に配置する設計が実務的に有効だ。
柱5: データ。データの分類（Classification）に基づくアクセス制御と暗号化を実施する。金融機関では個人情報、取引データ、内部管理データなど、データの機密度に応じた多段階の保護が求められる。DLP（Data Loss Prevention）の導入と、データ分類ポリシーの策定が実装の核となる。
マイクロセグメンテーション実装の実際
ゼロトラスト実装の中核技術であるマイクロセグメンテーションは、ネットワークを細かいセグメントに分割し、セグメント間の通信をホワイトリスト方式で制御する技術だ。従来のネットワークセグメンテーションがVLAN単位での分割であったのに対し、マイクロセグメンテーションはサーバー・アプリケーション単位での通信制御を実現する。
金融機関でのマイクロセグメンテーション実装では、以下の3つの論理分離が典型的な設計パターンとなる。
- 勘定系セグメント: 口座管理、元帳、決済処理など、即時整合性が求められるコアシステム群。最も厳格なアクセス制御を適用し、外部からの直接アクセスを一切許可しない
- 情報系セグメント: CRM、データウェアハウス、レポーティングシステムなど、分析・管理用途のシステム群。勘定系からのデータ連携は一方向（勘定系→情報系）に限定し、情報系から勘定系への書き込みは原則禁止する
- チャネル系セグメント: インターネットバンキング、モバイルアプリ、ATMなど、顧客接点のシステム群。WAF（Web Application Firewall）とAPI Gatewayを前段に配置し、バックエンドへのアクセスをAPI経由に限定する
実装上の最大の課題は、既存システムの通信フローの可視化だ。マイクロセグメンテーションを導入するには、まず「どのシステムが、どのシステムと、どのポートで通信しているか」を完全に把握する必要がある。20年以上にわたって増改築を繰り返してきた金融機関のシステムでは、ドキュメント化されていない通信経路が必ず存在する。パケットキャプチャやフローログの分析による通信フローの可視化は、マイクロセグメンテーション導入の前提条件であり、この工程だけで数か月を要することも珍しくない。
FISC基準とゼロトラストの統合 — 矛盾なき実装戦略
FISC基準の「前提」とゼロトラストの「前提」の整理
FISC基準とゼロトラストを統合的に実装するためには、まず両者の「前提」の違いを理解する必要がある。
FISC基準の前提は、伝統的に「信頼できる領域を確保し、その領域を守る」という考え方に基づいている。物理的なセキュリティゾーン、ネットワークの境界制御、入退室管理など、「安全な場所を作り、そこにシステムを置く」発想だ。クラウド対応が進んだ第13版でも、この基本思想は維持されている。
ゼロトラストの前提は、「信頼できる領域は存在しない」という正反対の立場から出発する。すべてのアクセスを検証し、最小権限の原則を徹底し、侵害は起こり得ることを前提に設計する。
一見すると矛盾するように見えるが、実はこの2つの前提は補完関係にある。FISC基準が定める「守るべき資産の特定」「リスクの評価」「対策の実施」というフレームワークは、ゼロトラストの実装においても土台となる。違いは「対策の実施」のアプローチにある。FISC基準が「境界を設けて守る」ことを基本としつつクラウド時代の対策を追加しているのに対し、ゼロトラストは「境界に依存しない」対策を体系化している。
統合のポイントは、FISC基準の各項目をゼロトラストの5つの柱にマッピングすることだ。FISC基準のアクセス制御はゼロトラストの「アイデンティティ」と「データ」の柱に対応し、ネットワーク対策は「ネットワーク」の柱に対応する。このマッピングにより、FISC基準への準拠とゼロトラストの実装を一体的に進めることが可能になる。
統合アーキテクチャの設計パターン
FISC基準とゼロトラストを統合した実装アーキテクチャの設計パターンを、実際のプロジェクトで採用している3層モデルで示す。
第1層: 認証・認可基盤（Identity Layer）
統合IAM基盤を構築し、すべてのアクセス主体（人、デバイス、サービス）のIDを一元管理する。FISC基準の「利用者認証」「特権管理」の要件と、ゼロトラストの「すべてのアクセスを検証」の原則を同時に充足する。具体的には、IdP（Identity Provider）としてAzure ADやOktaを導入し、SAML/OIDCによるSSOを全システムに展開する。特権アカウントにはPAMを適用し、Just-In-Time（JIT）アクセスで必要な時だけ特権を付与する設計とする。
第2層: ネットワーク制御基盤（Network Layer）
マイクロセグメンテーションとSDP（Software Defined Perimeter）を組み合わせ、FISC基準の「ネットワーク管理」とゼロトラストの「最小権限アクセス」を統合する。オンプレミスの勘定系は従来のネットワークセグメンテーションを維持しつつ、SDPで通信を暗号化・認証する。クラウド上の情報系・チャネル系はクラウドネイティブなマイクロセグメンテーション（AWSのSecurity Groups、Azure NSGなど）で制御する。
第3層: 監視・対応基盤（Detection & Response Layer）
SIEM（Security Information and Event Management）とSOARを統合し、FISC基準の「ログ管理」「インシデント対応」とゼロトラストの「継続的モニタリング」を一体化する。すべてのログを統合SIEM基盤に集約し、相関分析によるリアルタイム脅威検知を実現する。検知されたインシデントはSOARプレイブックに基づき、初動対応を自動化する。
【現場の声】SESエンジニアが直面するFISC×ゼロトラストの実装課題
統合アーキテクチャの設計パターンは理論的には整理できるが、現場では理想と現実のギャップに直面する。SESエンジニアとして多くの金融機関のプロジェクトに参画してきた経験から、よくある実装課題と対処法を共有する。
課題1: レガシー勘定系がゼロトラストに対応できない。COBOLベースの勘定系やメインフレーム上のシステムは、SAML/OIDCによるSSO統合やAPIベースの認証に対応していないことが大半だ。対処法として、レガシーシステムの「前段」にゼロトラスト対応のプロキシレイヤーを配置する。レガシーシステム自体には手を入れず、アクセス経路にゼロトラストの制御を挟む「ラッピング」アプローチが現実的だ。
課題2: PoCから本番移行のギャップ。ゼロトラストのPoCは比較的スムーズに進むことが多い。問題は本番移行だ。PoCでは数十ユーザー・数システムで検証するが、本番では数千ユーザー・数百システムにスケールする。特に、マイクロセグメンテーションのポリシー数が爆発的に増加し、管理が破綻するケースがある。段階的なロールアウト計画と、ポリシー管理の自動化ツールの導入を本番移行前に設計しておくことが不可欠だ。
課題3: DevSecOpsとセキュリティの「共存」。開発速度とセキュリティはしばしばトレードオフの関係に見えるが、DevSecOpsのアプローチで両立が可能だ。CI/CDパイプラインにSAST（Static Application Security Testing）とDAST（Dynamic Application Security Testing）を組み込み、セキュリティチェックを開発プロセスの一部として自動化する。「セキュリティレビューのためにリリースが2週間遅れる」という状況は、パイプラインの自動化で解消できる。FISC基準が求める「脆弱性管理」をCI/CDに統合することで、基準準拠と開発速度の両立が実現する。
TLPTとセキュリティ検証 — 「守り」から「攻め」のテストへ
TLPTとは何か — 従来のペネトレーションテストとの違い
TLPT（Threat-Led Penetration Testing: 脅威ベースのペネトレーションテスト）は、金融庁が推奨するサイバーセキュリティテストの手法であり、従来のペネトレーションテストとは本質的に異なるアプローチだ。
従来のペネトレーションテストは、対象システムの脆弱性を網羅的にスキャンし、発見された脆弱性を悪用して侵入可能性を検証する。テストの範囲は事前に合意されたシステムに限定され、テスト手法も標準的なツール・手順に基づく。
TLPTは、「自社を実際に攻撃する脅威アクター（攻撃者）が、どのような手法で攻撃してくるか」を分析した上で、その攻撃シナリオを実際に再現するテストだ。特定の技術的脆弱性の有無ではなく、組織全体のサイバーレジリエンス（防御・検知・対応の総合力）を検証する点が最大の違いである。
TLPTの構成要素は3つのチームに分かれる。
- スレットインテリジェンスチーム: 対象組織に対する現実的な脅威を分析し、攻撃シナリオを策定する。業界動向、地政学的リスク、過去のインシデント情報を基に、「この組織を狙うとしたら、どの脅威アクターが、どの手法で攻撃するか」を具体化する
- レッドチーム: スレットインテリジェンスに基づく攻撃シナリオを実際に実行する。標的型メールの送付、フィッシングサイトの構築、ソーシャルエンジニアリングなど、実際の攻撃者と同等の手法を用いる
- ブルーチーム: テスト対象組織の防御側チーム。TLPTの実施を事前に知らされず、実際のインシデント対応と同じ体制で検知・対応を行う。この「事前非通知」がTLPTの実効性を担保する重要な要素だ
金融庁が推奨するTLPTの好事例
金融庁が2025年6月に公表した「金融分野におけるITレジリエンスに関する分析レポート」では、TLPTの好事例として以下の3点が挙げられている。
好事例1: 自社固有の脅威インテリジェンスの活用。一般的な脅威インテリジェンス（業界全体の脅威動向レポート等）だけでなく、自社固有の脅威インテリジェンスを導出し、それを踏まえてテストシナリオを設定している事例だ。具体的には、自社の事業特性、システム構成、過去のインシデント履歴、取引先の脅威状況などを分析し、「自社に最も蓋然性の高い攻撃シナリオ」を策定する。このアプローチにより、汎用的なテストでは発見できない自社固有の脆弱性を炙り出すことが可能になる。
好事例2: ブルーチームへの事前非通知。ブルーチームにTLPTの実施を事前に通知せずに実施している事例だ。事前に通知すると、ブルーチームは「テストモード」で対応するため、通常運用時の実力を正確に評価できない。事前非通知にすることで、「実際の攻撃が発生した場合、自組織はどの程度の時間で検知し、どのような手順で対応するか」をリアルに検証できる。
好事例3: テスト結果の経営陣への適切な報告。TLPTで発見されたリスクについて、技術的な詳細だけでなく、経営上のインパクト（事業停止のリスク、規制上の影響、レピュテーションリスク等）を含めて経営陣に報告している事例だ。セキュリティは経営課題であり、テスト結果が現場のエンジニアだけで処理されるのでは不十分だ。
金融庁は2023事務年度に銀行を対象としたTLPTの実証事業を実施し、2024事務年度には保険業にも対象を拡大している。レポートではTLPTの有効性が確認されたとされており、今後さらに多くの金融機関に導入が広がることが予想される。
TLPTを外部委託する際の選定ポイント
TLPTは高度な専門性を要するため、多くの金融機関は外部のセキュリティベンダーに委託する。実際のプロジェクトでの経験から、ベンダー選定時の重要ポイントを整理する。
選定ポイント1: 金融業界での実施経験。TLPTの品質は、スレットインテリジェンスの精度に大きく依存する。金融業界特有の脅威（不正送金、インサイダー取引に関わるデータ窃取、ATMジャックポッティング等）を理解したインテリジェンスチームを擁しているかが重要だ。
選定ポイント2: レッドチームの攻撃能力。自動化ツールの実行だけでは、高度な攻撃者を模倣できない。手動でのエクスプロイト開発、ソーシャルエンジニアリングの実行能力、C2（Command & Control）インフラの構築・運用能力を持つレッドチームかどうかを確認する。
選定ポイント3: 安全措置と緊急停止手順。TLPTは実環境に対して実際の攻撃を行うため、意図しないシステム障害やデータ破損のリスクがある。テスト実施中の安全措置（本番データへのアクセス制限、攻撃のエスカレーション基準）と、問題発生時の緊急停止手順が明確に定義されているかを確認する。金融機関のシステムは「止められない」という制約があるため、この点は特に厳格に評価すべきだ。
選定ポイント4: 報告書の品質。発見事項の列挙だけでなく、攻撃チェーン（一連の攻撃ステップ）の再現手順、検知の成否、対応の改善提案を含む包括的な報告書が提供されるかを確認する。優れた報告書は、発見事項をFISC基準の該当項目にマッピングした形で整理されており、監査対応にもそのまま活用できる。
金融セキュリティの実装パートナー — テンファイブの支援領域
FISC対応・ゼロトラスト導入・セキュリティ人材の提供
本記事で解説してきた金融セキュリティの各テーマ — FISC基準の実装、ゼロトラスト・アーキテクチャの導入、TLPTの実施 — に共通して求められるのは、基準の「行間を読む」力と、現場での実装経験だ。
テンファイブ株式会社は、金融情報システム開発に20年以上にわたって携わり、セキュリティ領域で以下の支援を提供している。
- FISC基準対応支援: 第13版の改訂内容を踏まえた現行システムのギャップ分析、対策計画の策定、実装支援。基準の各項目を具体的な設計要件に翻訳する「行間を読む」作業を、経験豊富なエンジニアが担当する
- ゼロトラスト導入支援: 現状のセキュリティアーキテクチャの評価から、ゼロトラスト移行のロードマップ策定、PoCの実施、本番環境への段階的導入まで、一貫した支援を提供する。レガシー勘定系が残る環境での段階的アプローチに強みを持つ
- セキュリティ人材の提供: FISC基準を理解し、かつクラウドセキュリティの設計・実装ができるエンジニアの提供。金融特有のドメイン知識とセキュリティの専門性を兼ね備えた人材は市場で希少であり、テンファイブの強みのひとつだ
- DevSecOps導入支援: セキュリティチェックをCI/CDパイプラインに統合し、開発速度とセキュリティの両立を実現する。金融システム開発の上流工程からセキュリティを組み込む「シフトレフト」の設計を支援する
20年以上の金融セキュリティ実績
金融セキュリティの本質は、「技術的な対策を積み上げること」ではなく、「ビジネスを止めないセキュリティを設計すること」にある。過剰なセキュリティは業務を阻害し、不十分なセキュリティはインシデントを招く。このバランスを見極めるには、金融業務への深い理解と、セキュリティ技術の実装経験の双方が不可欠だ。
テンファイブは、TISインテックグループ、東京スター銀行、三菱総研DCSなど金融機関向けの開発に20年以上携わる中で、このバランス感覚を組織として蓄積してきた。COBOLベースの勘定系からクラウドネイティブな情報系まで、混在環境でのセキュリティ設計に対応できる人材を擁している。
FISC基準第13版への対応、ゼロトラスト・アーキテクチャの導入、DevSecOpsの実装 — いずれも「何をすべきか」は公開情報で把握できる。しかし、「どう実装するか」は、現場を知るエンジニアにしか答えられない。金融セキュリティの実装に課題を感じている方は、ぜひテンファイブにご相談いただきたい。20年以上の金融セキュリティ実績に基づく実務力で、プロジェクトの成功をサポートする。
