金融機関を取り巻く脅威の現状とガイドラインの策定
今やありとあらゆる業種がサイバー攻撃のターゲットになっています。中でも、最も長く、最も執拗に狙われ続けてきたのが金融業界でしょう。多額の資金と個人情報を直接扱う金融機関は、長きにわたりフィッシング詐欺や不正送金といったサイバー攻撃に狙われてきました。
もちろん、金融機関側が何の手も打たなかったわけではありません。むしろポリシーの策定やリスクベースでの評価にはじまり、それ以前から整備してきた不正防止の仕組みを生かしつつ、一般的な企業以上にさまざまな技術的対策を講じてきました。さらに、利用者向けの注意喚起も展開しています。
しかし、攻撃と防御はいたちごっこと言われるとおり、一連の対策を見越してサイバー攻撃はさらに巧妙化しています。近年では、仮想通貨取引所の従業員を狙ってマルウェアに感染させ、システムを侵害して多額の被害を与えるなど、より高度な手口が報じられています。
こうした傾向を踏まえ、金融庁は2024年10月4日に「金融分野におけるサイバーセキュリティに関するガイドライン」（以下、ガイドライン）を公表しました。別記事（https://www.nri-secure.co.jp/blog/guidelines-for-cybersecurity-in-the-financial-sector）にあるとおり、最新動向を踏まえてより詳細な対応事項が具体的に記されていることが特徴です。
A銀行の取り組み
＜課題＞手作業が多く属人的となっていた特権ID管理
ガイドラインの対応事項の一つが「認証・アクセス管理」です。
この項目では、ユーザ（従業員）やシステムのアクセス権限を必要最小限に制限し、アカウントの作成から使用、終了に至るライフサイクルを管理して定期的に操作履歴をレビューすること、中でもシステムの起動や停止、設定変更が行える特権アカウント（特権ID）については、多要素認証を組み合わせたり、アカウントの時間制限を加えたりするなどして、特に厳格に管理するよう求めています。
こうした要請に応えるため、地方銀行のA銀行では「SecureCube Access Check（以下、Access Check）」を採用しました。
A銀行では、オンプレミス環境の事務センターとパブリッククラウドを組み合わせたシステムを運用してきました。その中で、システム部門の行員や、リモートメンテナンスを実施する保守ベンダーが利用する特権IDについては、表計算ソフトで作成した台帳で、手作業で管理していました。
また、アクセス管理についても、ルータや回線での物理的な制御による運用にとどまっていました。
つまり「誰が、いつ、どのサーバやアプリケーションに対してアクセスできるか」の承認プロセスはワークフロー化されておらず、多要素認証やアクセス制御も不十分で、手運用による抜け漏れのリスクもありました。加えて、実際のログと突き合わせての監査の手間も少なくありませんでした。
＜対策＞迂回アクセス検知など豊富な機能を備えたSecureCube Access Checkを採用
A銀行では、こうした属人的な特権ID管理から脱却し、ガイドラインに準じた運用を実現するため、知見のある日立製作所（以下、日立）、インターネットイニシアティブ（以下、IIJ）のアドバイスを得ながら特権ID管理ソリューションの選定を進めました。
一般的な特権ID管理ソリューションならば、ワークフローに基づく特権IDの申請・承認・払い出しやアクセス制御、操作ログの取得、監査といった基本的な機能を備えています。ただしA銀行の場合、さらにいくつか譲れない要件がありました。
最も重要視していたのが、迂回アクセス検知機能です。
特権IDでシステムにアクセスする場面は、基本的にあらかじめ申請した作業が主となりますが、時には緊急対応のために急いでアクセスしなければならない場面が生じます。そんなときはやむを得ず、ゲートウェイのサーバを介する本来の経路を迂回し、直接管理対象にログインして作業してしまう場合があります。
A銀行ではそうした事情を理解しつつも、迂回アクセスを確実に把握し、そこに至った背景を確認できる体制を整えたいと強く考えていました。また、不正なアクセスを検知するという観点でも、迂回アクセスの検知は重要視していました。
ゲートウェイ型の特権ID管理製品で、迂回アクセス検知を十分に行うことができる製品となると限られます。加えて、特権IDに対する多要素認証も実現できる製品となると、Access Checkが最適なソリューションでした。
また、A銀行ではオンプレミスのWindows、Linux、AIXに加え、クラウド基盤も活用しており、多様なプラットフォームに対応している必要がありました。同時に、可能な限り運用を簡素化するため、別途踏み台サーバを用意せずに導入できることもポイントでした。
これらの多様な要件をすべて満たしたのがAccess Checkでした。他の選択肢が「あちらを立てればこちらが立たず」だったのに対し、Access Checkは迂回アクセス検知、多要素認証、多様なプラットフォームへの対応、そしてシンプルな構成が実現できることから、A銀行は採用を決定しました。
＜効果＞金融庁のガイドラインに準じた特権ID管理体制を迅速に整備
A銀行ではSecureCube Access Checkを利用し、約150台のサーバ環境において、利用する特権IDを管理しています。
特権IDを用いて作業する必要が生じた際にはワークフローを用いて申請・承認を行い、実際のアクセス時にはソフトウェアトークンを組み合わせた多要素認証を実施します。リモート保守ベンダーが作業を行う場合は、ハードウェアトークンによる多要素認証を実施しており、ユーザごとにトークンを使い分けています。
一連のアクセス履歴はAccess Checkのログで確認できるほか、迂回アクセスの有無もダッシュボード上でチェックできます。インターフェースの使いやすさも、A銀行が気に入っているポイントの一つです。
こうしてA銀行はAccess Checkによって、金融庁のガイドラインに準じた特権ID管理を、AIXで動作する重要システムも含めて実現しています。属人的な管理から脱却し、ワークフローに基づいて適切な管理が行える点も、大きなメリットだと捉えています。
Access Checkの導入作業は半年で完了しました。通常ならば年単位のプロジェクトとなるところですが、日立の支援を得ながら、アクセスポリシーを設計していくことで、スピーディな導入を実現しました。日立の知見に加え、能動的に取り組むA銀行の文化が功を奏し、プロジェクトを成功裏に進めることができました。
A銀行ではAccess Checkの導入によって、ガイドラインに準拠したセキュリティ対策のスタートを順調に切ることができました。引き続き、三カ年計画で立てたロードマップに沿って、ログ分析や脆弱性診断といった対策を着実に進めていく方針です。
規模を問わず求められる金融庁のガイドライン準拠を支援
このようにオプションも含め、金融機関が求めるさまざまな要件に応える多様な機能を総合的に備えているのがAccess Checkです。
今まではメガバンクへのサイバー攻撃が主流でしたが、近年は、守りの手薄なところを確実に狙うサイバー攻撃も増えています。規模が小さい地方銀行や信用金庫も攻撃のターゲットとなっているのです。
こうしたトレンドに加え、金融庁のガイドラインを踏まえると、厳格な特権ID管理は規模を問わずあらゆる金融機関にとって必須の対策と言えるでしょう。要求事項は多岐にわたりますが、そんな中でも適切なソリューションとパートナーを選び、主体的に特権ID管理に取り組むことがポイントと言えます。
