NTTデータのITスペシャリストが語る"推しの技"――「セキュリティインシデント」「SWA視点」「XonOps」とは
NTTデータでは、金融分野の技術集約組織として金融高度技術本部が設けられており、先進的かつ高難易度な要件を実現する、さまざまな領域の「ITスペシャリスト集団」が活躍している。そのようなITスペシャリストが登壇し、“推しの技”を披露するシリーズ。今回は「インシデント対応」について、各スペシャリストが解説した。アーカイブ動画
部門横断でNTTデータの金融システムを支えるITスペシャリスト集団
NTTデータは、システムインテグレーション、ネットワークシステム、グローバルデータセンター、クラウドなどの事業を国内外で展開しているNTTグループの1社、NTTデータグループにおける国内事業会社である。
NTTデータグループ全体の売上高は約4兆6400億円、従業員数は約19万8000人にもおよぶ。
その中で金融分野の売上高は約7500億円になる。さまざまな業界や企業を顧客に持つのが強みであり、国内金融市場におけるITサービスベンダーランキングでは1位を獲得。日本の金融インフラを名実共に支えている。
金融分野は第一金融事業本部~金融イノベーション本部まで、4つの本部がそれぞれお客様をもってシステム開発等を行う。本講演の主催組織である金融高度技術本部はこれら4つの本部に「金融システムの信頼性と先進性の両立を実現する」とのミッションを掲げ、部門横断で先進技術を提供している。
金融高度技術本部は、現在約400名のITスペシャリストが所属しており、さまざまな事業領域に対して、中小規模からミッションクリティカルな大規模システムまで手がけているのも特徴だ。
「育成コンテンツも充実しており、エンジニアリングを楽しみながら幅広い技術を身につけることができます」。
峯村氏はこのように述べ、講演セッションにバトンを渡した。
「準備」が最も大事。6段階対応フレームワークで「セキュリティインシデント」に備える。

NTTデータ
金融イノベーション本部 ビジネスデザイン室 セキュリティビジネス担当
部長 阿久沢 佑介氏
最初のセッションテーマは「セキュリティインシデント」だ。登壇したのは2004年に入社した阿久沢佑介氏である。阿久沢氏は、大規模な公共系システム開発プロジェクトなどを経験した後、2度の社内公募を経て2017年より金融分野のセキュリティ技術全般を担当、インシデント対応にも精通している。

阿久沢氏はまずは、セキュリティインシデントとはどのようなものかを、改めて解説した。システムへの不正アクセスやランサムウェアに感染するような事象を思い浮かべる人が多いと思うが、アプリのバグによりユーザーの個人情報を表示するような事象もセキュリティインシデントだと、阿久沢氏は説明した。
また、故障という不具合はそれなりに起きるため、対応方法は自然と身につくそうだが、セキュリティインシデントは頻度が高くないため、いざ発生した際にどのように対応すればよいのか、イメージできる人が少ないとも続けた。

一方で、阿久沢氏がフォローしている金融システムの数は300を超えるため、「それなりに発生します」と述べた上で、6段階からなるフレームワークで対応していることを述べ、それぞれのフェーズにおける対応を、詳しく解説していった。
</p
まずは「準備」フェーズである。ステークホルダーの特定においては、システムの運用者は把握していることが多いが、そのシステムのビジネス面における責任者、つまりオーナーは誰なのかは不明なことも少なくないため、明らかにしておくことがインシデント対応では重要であることを強調した。 その他、インシデントが発生した際に連絡する先や、連絡体制、教育やトレーニングの実施も重要だと述べた。

サーバー、Webサイト、さらには外部のサードパーティなど、システムに関連する環境下に置かれている情報が、どのようなものか把握することも重要だという。中でも時折あるインシデントのケースが、本来は削除しておくべき情報であったが、削除をしておかなかったためにユーザーの個人情報が流出してしまい、セキュリティインシデントとなることだ。
また、開発環境や検証環境のセキュリティ対策状況の把握も重要であり、その理由を次のように述べた。
「商用環境ではないので攻撃されても問題はないと考える人がいますが、次のターゲットを攻撃するための踏み台にされるケースもあるので、最低限の対策は必ず必要です」(阿久沢氏)
最近はサードパーティ関連のインシデントが多く発生していることから、業務委託先にどのような情報を預けているかも、しっかりと確認しておくことが必要だと続けた。

続いては「特定」フェーズであるが「検知は難しい」と阿久沢氏はまずは述べた。というのも、攻撃者は不正侵入したことを気づかれることなく、長く侵入していたい場合が多いからだ。
では、どうやって特定するのか、阿久沢氏はいくつかのポイントを挙げた。まずは、正常時と比べてデータの送信量が増えたようなケースだ。また、世の中で起きている不正アクセスの事象をチェックしておき、該当するシステムと照らし合わせるのも重要だと述べた。

実際にどれくらい検知が難しいものなのか、セキュリティが堅いであろうアメリカ軍のシステムが9カ月間誰にも気づかれず、不正に侵入されていた事例も示した。そしてこのような背景には、対策ソフトに気づかれないよう、侵入したシステム内に存在する正規のツールを使って攻撃を進める「Living off the land」というテクニックがあることも紹介した。

検知が確定したら、これ以上被害を拡大させないような対応を行う。阿久沢氏は「止血」と表現し、まずはネットワークケーブルを抜くなどの例を示した。
ただし、これらのインフラを停止することは、システムやサービスも止まることになる。ここで、先ほどの「準備」段階でシステムオーナーを特定していたことが効いてくる。システムやサービスをストップするかどうかは、オーナーが行う判断だからだ。
そのためセキュリティ担当者は、オーナーが是非を判断するための材料を、速やかに集め報告する役割も担う。

現場に到着したら、不正アクセスはいつから行われていたのか、侵入はどの領域までだったのかなどの調査における証拠品となる、各種ログやメモリイメージなどの、フォレンジックデータを取得していく。
ログの保管期間よりも前から攻撃されていたケースもあるため、「ログの保管期間は慎重に設計する必要があります」と、阿久沢氏は補足した。

フォレンジックデータを取得し解析が終わったら、攻撃を受けたサーバーに残っているかもしれないマルウェアなどを根絶していく。ただ「rootkit」と呼ばれる、攻撃者の痕跡が見えないようにするツールを利用されている可能性があるため、完全な除去は難しく、ディスクをフォーマットし、OSやミドルウェアなどを再びインストールしていくのが基本だという。

再構築が済んだら、システムやサービスを以前の状態に戻す復旧作業に移るが、ここでも判断はシステムオーナーが行う。また、復旧した後も根絶しきれていない可能性もあること、攻撃者が執拗に狙ってくる可能性もあるため、監視を重点的に行うことも大事だ。

最後のフェーズは「教訓」だ。セキュリティインシデントはその特性から、事例や関連情報が公に出ることが少ないため、インシデントが発生したことは反省しつつ、教訓として社内で共有することで、再発防止や準備フェーズで紹介した教育につなげていくことが重要だという。
「骨の髄まで無駄にしません」と阿久沢氏は言い、次のようにメッセージでセッションを締めた。
「セキュリティインシデント対応で一番大事なのは、『準備』をしっかりと行うことです。システム故障とは対応が異なることが多いですが、準備をしていれば、発生した際にもどのように対応すればよいか分かっているため、迅速に動くこともできます」(阿久沢氏)
CI/CD両面をミクロ・マクロ視点で捉えるSWA視点が、インシデントを解決する

NTTデータ
金融高度技術本部 基盤技術部
課長代理 鈴木 孝誌氏
続いてのセッションテーマは「SWA(ソフトウェアアーキテクト)が見抜いた危機集」だ。
登壇したのは2010年に入社した後、金融機関向け基幹系システムのJavaソリューション開発に従事。その後、決済ITサービス事業部で性能監視システムの開発を担当した後、2025年に金融高度技術本部に異動、現在はモダナイゼーションに関する性能問題の解決プログラミングなどに携わる、鈴木孝誌氏である。

鈴木氏はまずソフトウェアアーキテクトの役割や特徴について、システム全体の設計ではどのようなパーツを組み合わせれば安全に動くのかの青写真を描くことであり、日常に例えると建築士のような仕事だと紹介。その他の役割についても同様に、具体的な取り組み内容を日常に例えながら分かりやすく説明した。

続いて、単体テストや機能テストなどの工程で問題はないとされていたのに、なぜシステムテストの工程になると、問題が発生するのかについての見解を6つほど述べた。例えば、各種機能やシステムが結合することにより複雑性を増すことで、タイミングのズレやデータの受け渡しミスなどが生じることが挙げられる。
また、仕様変更やバグの修正を頻繁に行っている場合、テスト対象のコードが常に変化しているため、テストの安定性が損なわれるとの理由もあると述べた。


システムテストはリリース直前、開発の最終工程で行われるため、この段階で問題が発生すると、修正コストが高くつく。また、チームのモチベーション低下、さらにはユーザーも含めたステークホルダーからの信頼損出という、さまざまな問題につながることが少なくない。
だが、システムテストにおける問題発生を防ぐことは、先のようにさまざま理由や背景があることもあり、「問題を起こさないようにすることは難しい」と鈴木氏は言う。しかし「早期に検知し解決することが重要であり、そこでSWA視点が活きます」と述べ、実際にSWA視点で早期にシステムテストの検知・解決を実現した事例を2つ紹介した。

1つ目の事例は「論理コア数96のシステムでCPU使用率が5000%超」という、いわゆるCPUが高騰しているケースだ。鈴木氏はSWA視点に則り、原因と考えられる4つの仮説を立てた。そしてその中から、不要なメモリ領域を自動で開放するGC(garbage collection)などが、CPUを消費していることが原因だと突き止めた。

原因が特定できると、さらに詳しい症状を分析すると共に、対処方法などもかためていった。鈴木氏はこのようなアプローチを「カルテ」と称し、実際、それぞれの対応の具体的な詳細も示した。
例えば対応では、要件上不要なネイティブメモリの使用はとりやめると共に、スレッド数の条件を設ける、といった具合だ。また先ほどの阿久沢氏の「回復」フェーズに近しい経過観察対応では、GCログやジョブの実行時間を確認することが重要だと述べた。

また、高スペックなCPUでもアルゴリズムの種類によっては、すぐに性能の限界を超えてしまうことを指摘した。具体的にはスライド右下のようなアルゴリズムであり、特にデータ構造の操作やソートなどを行う際は意識することが大切だと補足した。

もう一つポイントを紹介した。それぞれの機能や役割における処理時間の代表、一般的なスピードを認識しておくことだ。こちらもまさに阿久沢氏が説明した、一般的な事象にアンテナを張っておくことが重要との文脈に近いと言えるだろう。

2つ目は本番相当の環境テストを行ったが、結果が合わないという問題だ。こちらも事例1と同じくSWA視点で原因を探ると、4つの疑わしい事象が上がってきた。その中から鈴木氏は「データ量分布の違い」「同時実行数の差や種類」が疑わしいと目星をつける。

ここからのアプローチは事例1と同じく、カルテを作成し現象を深堀りすると共に、対処方針などを明確にしていった。ちなみに診断名は「スレッドアンセーフにより稀に正しい結果が得られない」である。 分析を進めていくと予測したとおり、同時期に動いていた別スレッドで一部の情報が上書きされていたことで、スレッドアンセーフな状態となっていたことが分かった。そこで、同情報を修正することで対応した。


だが、すべてのスレッドをセーフにすると場合によっては性能が犠牲になる可能性が高いため、注意が必要だと補足すると共に、問題となり得るような状態も示した。また、Javaでよく使用されるクラスにおいてもスレッドアンセーフが多いという。実際に6つのクラス例を示すと共に、「使用する際は注意が必要です」と述べた。

仕様が説明書のように示されるJavadocを活用し内容を確認することでも、鈴木氏が紹介した注意点が示されているので、「目を通しておくことをおすすめです」と、続けた。

鈴木氏はセッションの内容を振り返り、問題は早期に発見するべきであり、実現するためにはCI/CDなどによる日々の検知が重要など、3つの提言とそれぞれのベストプラクティスを併せて紹介した。


さらに問題発生を低減させるためには、人は必ずミスをするとの前提で工程を設計したり、人に頼らない仕組みづくりが重要であること。そのような対策を講じても問題が発生した場合には、まさにセッションにおけるSWA思考を活用し仮説を立て、一つずつ問題を解決しておくことが重要であることを繰り返した。

そして最後に、SWAは開発・運用両方のライフサイクルにおいて、ミクロ・マクロの視点で取り組むこと。解決策を見つけるには、それぞれの領域での知識や経験が必要であり、「SWAとして成長するためには同領域での知見を積むことが重要です」と述べ、セッションを締めた。
XonOpsを使ったインシデント対応の改善事例

NTTデータ フィナンシャルテクノロジー
決済イノベーション事業部 第二担当
主任 伊藤 祐一氏
講演セッション最後のテーマは「XonOps」という、インシデント管理サービスについてだ。登壇したのはXonOpsを企画・発案した、NTTデータ フィナンシャルテクノロジーの伊藤祐一氏である。
NTTデータ フィナンシャルテクノロジーは、NTTデータグループにおける金融分野の中核企業の一つであり、2022年に設立された。保険や銀行、政府系金融機関やクレジットといった金融領域でシステム開発を担ってきたNTTデータシステム技術と、NTTデータ・フィナンシャルコアの統合によるものである。 伊藤氏がインシデントに関わるようになったのは2010年からであり、2018年ごろからインシデント対応の重要性に気づく一方で、運用や保守といった業務プロセスにおいて、多くの課題があることも考えるようになっていった。

例えば、運用現場では24時間365日体制で対応している場合は、人員コストが高まったり、手動対応のため作業員の負荷や工数も同じく増加したりするといった具合だ。保守現場においても、アラートを減らすポイントに気づいてはいるのに、承認の流れなどさまざまなルールや制約により、実際に取り組むことが難しかったり、迅速に行えなかったりといった点などである。「お客様からもっと早く連絡が欲しかった」、と言われることも少なくないという。

そこで自動化などによりこれらの課題を改善していこうと考えたのである。改善ポイントは大きくは3つだ。1つ目は、必要なアラートだけを選別するために、ナレッジを与えてトリアージするような機能である。
2つ目は、属人化を防止するためにナレッジを蓄積することで、誰でもインシデント対応ができるような体制を整える。3つ目が、発生したアラートを一覧化したものや、それぞれのアラートにおける対応ステータスやステークホルダーとのやり取りといった情報を、Web上で簡便に見ることができるような機能だ。

こうして開発されたのがXonOpsである。これまでは大勢の担当者がアラートを確認していた状況が改善され、自動でインシデントアラートがトリアージされていることが分かる。運用担当者は、その中から本当に確認や復旧が必要だと判断したインシデントのみを、保守へ連絡する。
運用サイドから連絡を受けた保守サイドも、XonOpsに蓄積されているナレッジをベースに、どこまでの対応をすべきか、まずはリモートで対応することができる。連絡は営業担当にも自動でいくため、お客様への連絡が遅くなることもない。

それぞれの改善フローにおいて、伊藤氏はさらに詳しく解説した。まずは、インシデントのトリアージであるが、こちらは初動での利用だけでなく、保守担当者がインシデントの状況を判断する際にも使われている。

関係者に連絡を行う際にも、ナレッジの蓄積が効果を発揮する。連絡メールにトリアージの判断内容を簡潔に記載しているため、経験の乏しいメンバーでも一目で重大なインシデントなのか、そうでないかが分かるようになっているからだ。

インシデント対応の可視化においては、実際にWebに表示しているUI画面を紹介した。緊急度やインパクトをカラー表示することで、こちらも誰でも瞬時に状況が確認できるようになっていることが分かる。

XonOpsの導入により、これまでは初動や調査に約15分かかっていたのが、約5分に短縮された。その後の復旧フローなどにおいては特に変わらないが、全体として約3分の2に工数が削減されたこととなる。

またXonOpsの導入後は、1000件以上の不要なアラートが、ナレッジを蓄積していくことで1カ月には約91%にまで減少、さらに半年経つと95.5%減るという効果を得た。

保守担当者が1人で1日100件ほどのアラートメールを開封し、対応を判断した上で各所に連絡を行う。このような現場への導入事例の効果も示した。作業負担は約10分の1に減少することに加え、これまで連絡が遅いと顧客から上がっていたクレームも0件となった。

インシデントの判断業務における効率化の実例も紹介した。以前は10ほどの顧客を15名ほどで対応していたが、顧客ごとに様式が違うなどナレッジの管理方法が異なっていたことなどもあり、1日1000件もの不要アラートが生じていた。担当者も改善したいと考えていたが、目の前の業務に忙殺されていてできずにいた。


XonOpsを導入したことで、ナレッジの一元化ならびにトリアージの自動化が実現。15名の負荷は大きく減少すると共に、浮いた時間をナレッジ蓄積業務に充てることで、さらにトリアージの正確性は高まっていった。

伊藤氏は最後に、「特別なリプレースや大がかりな開発は不要で、今ある体制を活かしたまま段階的に始めることができます」とXonOpsの特徴を改めて述べ、セッションを締めた。
【Q&A】参加者からの質問に登壇者が回答
セッション終了後は、質疑応答時間が設けられた。
Q.AIの活用や恩恵について知りたい
阿久沢:AIの重要度は高まっており、特に「検知」フェーズでの役割を期待されています。たとえば、単品のログでは検知が難しい侵害や予兆を、色々な部分のログを突き合わせて見つける「SIEM(Security Information and Event Management)」というシステムがあります。 このSIEMの分析をAIで高度化することで、今まで気づけなかった侵害の検知につなげようというソリューションが、活発に開発されています。
Q.テスト業務への投資を、経営層や投資家に理解してもらう際のポイントは?
鈴木:テストを実施することで機能やシステムの変更がしやすくなるなど、アジリティが高まるとの視点で理解してもらうのがいいと考えています。
Q.トリアージの判断基準を知りたい
伊藤:ナレッジを登録、蓄積していくときにトリアージの判断基準も同時に行う、処理するような設計となっています。
NTTデータ
https://www.nttdata.com/jp/ja/
NTTデータの採用情報
https://www.nttdata.com/global/ja/recruit/
NTTデータ金融分野の採用ポータルサイト
https://finance-hr.nttdata.com/
おすすめイベント
関連するイベント












