最上級のセキュリティ確保が求められる、銀行セキュリティチームに質問してみた｜みんなの銀行

欧米が先行する次世代の銀行のカタチ＝デジタルバンク。「みんなの銀行」は国内で初めて誕生したこともあって、SNS上では「ちゃんとした銀行なの？」「セキュリティは大丈夫？」といったセキュリティ面を心配される声もちらほら……。

今回は、みんなの銀行のセキュリティの要であるゼロバンク・デザインファクトリーのセキュリティチームより、二宮賢治さん（CISO）、高橋明さんのお二人に、同じくゼロバンク・デザインファクトリーで、サーバーサイドの開発を行うエンジニアの山﨑が話を聞いていこうと思います。
※この記事はオウンドメディア『みんなの銀行 公式note』からの転載です。

銀行セキュリティの要！　ゼロバンク・デザインファクトリーのセキュリティチーム、二宮さんと高橋さんってこんな人

――最初に自己紹介をお願いします。

二宮　大学卒業後某SIベンダーに入社し、SEとしてインターネットバンキングシステムの開発、顧客導入等を経て、某ネット銀行の設立に携わりました。その後、設立したネット銀行に籍を移し、IT基盤やセキュリティを担当。CSIRTや社内SOCの立ち上げ、運営に従事してきました。みんなの銀行とゼロバンク・デザインファクトリーにおいては、サイバーセキュリティ対策の責任者をしています。

高橋　大手ITベンダーのグループ会社にてメガバンクの営業店システムの基盤構築、メガ信託銀行のシステム子会社にてグループ会社各社のシステム基盤構築・維持などに携わっていました。その後、ネット銀行、ネット証券、外資系生命保険会社を経て現職です（みんなの銀行、ゼロバンク・デザインファクトリー兼任）。ネット銀行では、インターネットバンキングの基盤・社内イントラを担当後、システムリスク管理やセキュリティに携わり、以後のキャリアにおいてはCSIRT構築・運用等、サイバーセキュリティ対策に携わっています。

セキュリティチームの仕事って？

――セキュリティチームが担当する業務を教えてください。

二宮　セキュリティチームでは、サイバー攻撃への対策の企画、対応体制・手順の整備、サイバー攻撃発生時には対応の優先順位付けを行うとともに、対応を指揮しています。また、サイバー攻撃の予兆や、脆弱性の情報を収集・調査し、それらの対応を指示するのも私たちの仕事です。CSIRT（シーサート）やSOC（ソック）といった組織の運営も担っています。

——CSIRTとは？

高橋　CSIRTとはComputer Security Incident Response Teamの略で、インシデント発生時の対応に焦点を当てたセキュリティチームのことです。サイバー攻撃の検知から止血対応、復旧、再発防止までの様々な対応を行います。

——なるほど（このあとも知らない言葉がたくさん出てきそうだ……）。主にインシデント発生時の対応を行うチームのことなんですね。

——では、SOCとは何でしょうか？

二宮　SOCはSecurity Operation Centerの略で、サイバー攻撃の発生、またはその予兆を検知するための各種ログやアラートの監視、分析を行っています。アラートを受けたり不審なログを見つけたら調査を行い、必要に応じ攻撃元ブロック等の対応を行います。

——複雑化、高度化するさまざまなサイバー攻撃がある中で、しっかりとした検知と対応が求められているのですね。

二宮　そうですね、セキュリティ監視の仕組みについては、攻撃手法の変化に応じて日々改善を行っています。

高橋　セキュリティチームとしては、その他にも新規システム開発案件や、新規導入サービスに対するセキュリティ関連のリスク評価を行ったり、自らセキュリティ対策製品導入の企画、推進も行い、セキュリティの維持・強化に努めています。

様々な診断でセキュリティを確保！　アプリケーション脆弱性診断・プラットフォーム診断・ペネトレーション診断etc

——セキュリティを確保するために行われるテストについて教えて下さい。

二宮　1つ目に、「アプリケーション脆弱性診断」を行います。これは、開発したアプリケーションに、クロスサイトスクリプティングのような一般的な脆弱性攻撃や、認証をかいくぐることができないかといった、アプリケーション実装上の脆弱性などを発見するためのテストです。

——この診断は私も、開発エンジニアの立場としてテストしてもらったことがあります。基本的なところは押さえているつもりでも、第三者から網羅的なテストを実施してもらえると非常に安心感がありました。特に認証周りは何回でもテストしてもらいたいくらいです！　他にはどんなことがありますか？

二宮　2つ目に、「プラットフォーム診断」といって、構築した基盤、主にアプリケーションの実行環境に脆弱性が無いかを確認します。不要な穴（ポート等）があいていないか、脆弱性のある設定はないか等をテストします。

高橋　さらに、「ペネトレーション診断」といって、マルウェアに感染したことを前提に、どこまで侵入を拡大できるかを確認するようなテストも行っています。ほかにも「ホワイトハッカー診断」というハッカー（といっても認定された正義のハッカー）にブラックボックス的にアプリを渡して、様々な角度から脆弱性をあぶりだしてもらうテストも行っています。

——セキュリティ確保のために、こんなにたくさんのテストを行っているとは知りませんでした！　私が言うのも変ですが、さすが銀行（笑）。

免許事業である「銀行」が求められるセキュリティレベルは高い

——そもそも銀行は、一般の事業会社に比べてセキュリティが厳しいイメージがありますが、実際はどうなのでしょうか？

二宮　そのとおり、銀行はお客様の大切な財産（お金）をお預かりしていることから、一般の事業会社よりも高いレベルのセキュリティが求められています。そのため、FISC（金融情報システムセンター）の定める安全対策基準にしっかりと準拠したうえ、NISTのSP800や、FFIEC CATといった米国のセキュリティスタンダードも意識しています。また、クレジットカードやデビットカードの発行においては、PCI-DSSといった業界基準もクリアする必要があります。

二宮　例えば、みんなの銀行では、認証の3つの要素である「記憶、所有、生体」について、どれか一つが盗まれても、なりすましや不正送金ができないようにしています。ID/パスワードが盗まれても大丈夫、ということです。

また、お客様の個人情報については、二重三重のファイアウォールや強度な暗号化を行うとともに、たとえ私たち行員であっても機密情報にはアクセスできないように厳しく制限しています。
一方、行内業務やOA環境においても複数のセキュリティ機能を導入して、多層防御を実現しています。さらには、24時間監視を行い、何かあれば即時に対応できるような体制をとっています。

——前述された様々な基準については 「アプリケーション脆弱性診断」などのテストをもって基準を満たしているとされるものでしょうか？　それとも別の診断やテストがあるのでしょうか？

二宮　PCI-DSS以外は基本的に診断やテスト、審査はありません。それぞれが、準拠すべき対策のレベルを明確に示されているので、自社でチェックすることになります。PCI-DSSについては、QSA（Qualified Security Assessor：審査機関）によって認定を受けるものとなります。

クラウドと銀行｜責任分界点の正しい理解とセキュリティ対策

——銀行であるからこそ、満たすべき基準があるのですね。最近よく耳にするゼロトラストは銀行でも必要な考え方でしょうか？

高橋　ええ。ゼロトラストは、社内環境であっても信頼せず、外部とのやりとりだけでなく、内部間を含むすべてのトラフィックを把握・識別し、すべてのエンドポイント（PC等）の挙動も監視していく考え方ですが、銀行においては、以前からこのような考え方を取り入れ、マルウェア等の侵入を前提としたセキュリティ対策や、内部不正を含む不正の防止に取り組んでいます。

——ゼロトラストが主流となっている背景には、クラウドの導入というものがあると思います。みんなの銀行も、Google Cloud Platformを利用するなどクラウドがメインのプラットフォームになっていますが、それによる運用の難しさや、クラウドだからこそのメリットがあれば教えて下さい。

二宮　クラウド利用においては、クラウド事業者が提供する各種サービスの様々な設定をきちんと理解・把握・管理しないと、場合により思わぬところにセキュリティホールが空いてしまうことがあります。クラウド事業者と私たち銀行側との責任分界点を正しく理解し、必要な箇所にしかるべきセキュリティ対策を行っていく必要があります。

——「正しく理解して利用する」ことが重要。確かにそうですね。一方でクラウドのメリットは何でしょうか？

高橋　一定のセキュリティ機能があらかじめ用意されていることで、コストや時間をかけずにセキュリティ対策を実現できるという点です。また、DDoS攻撃のような大量のトラフィックを送り付ける攻撃への対応は、オンプレでは難しいですが、クラウドであれば、その規模によって吸収できるという利点もあります。そういったクラウドのメリットを活用して、セキュリティ対策を行っています。

開発とセキュリティ｜設計・開発段階で脆弱性を作りこまない

——最後にイチ開発者としての質問です。セキュリティを担保しつつもスピード感をもって開発を進めるために、開発者が気にかけておくべきこと、実践できることを教えて下さい。

二宮　前述した「アプリケーション脆弱性診断」のような、できあがったアプリケーションに対する診断に頼らず、設計・コーディングの段階で脆弱性を作りこまないようにしていただきたいです。診断による脆弱性の発見には限界がありますし、問題が見つかった時の手戻りによって多くの工数と時間がかかってしまうためです。

設計・コーディングの段階で脆弱性を作りこまないためには、開発者のみなさんには、アプリケーションの一般的な脆弱性にはどんなものがあり、どう対策すべきなのかを学んでおくほかに、世の中のセキュリティ事案についても興味を持って見ていただきたいと思います。サイバー犯罪者は、少しでもセキュリティの弱いところがあれば、そこにつけ込んできます。そのようなサイバー犯罪の手口に関する知識を持ち、皆さんの手で設計やコーディングといった開発の初期段階で、脆弱性を作りこまないようにしていただければ、そのことが、結果的にスピードを上げることになります。

(執筆者: みんなの銀行)