東京海上日動におけるセキュアな開発プロセスの取り組み

東京海上日動におけるセキュアな開発プロセスの取り組み NIKKEI Tech Talk #35 2025.07.24

自己紹介 2

自己紹介 3 宮島拓也（みやじまたくや）東京海上日動システムズ株式会社 ITサービス本部 ITサービス管理部サイバーセキュリティチームセキュリティスペシャリスト
経歴 2017年東京海上日動システムズ新卒入社 • 営業管理系の社内業務アプリの開発・運用 • レガシーシステムメイン、ちょっとSalesforce 2018年 SaaSエンジニアへ転向（部署異動） • Microsoft365、Salesforceの開発・運用 • スマホでの業務実現のため、Intuneなどを設計したり 2022年突然セキュリティに目覚め、セキュリティ基盤担当へ（部署異動） • セキュリティ共通システムの開発・運用 • 脆弱性管理システムやSIEMなど 2024年セキュリティ管理担当へ（部署異動） • セキュリティ改善プロジェクトの計画・推進 • 各システムのセキュリティ評価 • 各開発プロジェクトのセキュリティ設計支援 • インシデントレスポンス

東京海上日動システムズについて 4

東京海上日動システムズの概要 5 サイバーセキュリティチームの概要 2012年に発足 2025年現在で約30名の専任部隊東京海上日動とあんしん生命のセキュリティの戦略立案やポリシー策定、インシデントハンドリングや日々のモニタリングを行う東京海上グループのIT・デジタル戦略を担うシステム会社 Business
Established Number of Employees 東京海上グループのIT・デジタル戦略を担うシステム会社東京海上グループの情報システムの企画・提案・設計・開発・保守・運用・システム活用支援 1983年9月 2004年10月東京海上火災、日動火災のシステムグループ３社が合併して東京海上日動システムズ（株）が発足 1,736名（2025年4月現在）平均年齢は38歳

システム・案件の規模 6 システム約700 サーバ約7,000 開発案件約4,000/年業務端末約50,000

なぜ開発プロセス？ 7

なぜ開発プロセス？ 8 NIKKEI Tech Talk #35 「Webプロダクトの多層防御」というテーマでなぜ開発プロセスを？プロセスこそが、防御技術に実効性を与えるものだから開発プロセスルール通りにやりますね。
書いてないってことはいらないのか。 FW WAF ハードニング Proxy EDR・EPP リリース前診断パッチ適用 etc... ただ声を張り上げても全員には伝わらない

なぜ開発プロセス？ 9 NIKKEI Tech Talk #35 「Webプロダクトの多層防御」というテーマでなぜ開発プロセスを？プロセスこそが、防御技術に実効性を与えるものだから開発プロセスなるほど。やります。
FW WAF ハードニング Proxy EDR・EPP リリース前診断パッチ適用 etc... ...をやってください。システムにセキュリティを実装するのはセキュリティ担当ではない。だからこそプロセス化が必要。

東京海上日動の開発プロセスにおけるセキュリティ～これまで～ 10

東京海上日動の開発プロセスにおけるセキュリティ～これまで～ 11 開発プロセスにおけるセキュリティ品質の取組の歴史～2010 セキュリティ専門人材はまだおらず、リリース前に開発者がDASTツールでスキャン。 2011 セキュリティ専門人材が誕生。定期的な脆弱性診断プロセスが開始。公開Webアプリ用のセキュリティ要件とチェックリストが誕生。まだまだセキュリティ担当の関わりは薄い。 2021
散在するチェックリストを束ね、セキュリティチェックリストが誕生。セキュリティ担当が第三者評価するように。開発者はセキュリティを自然と意識しはじめ、セキュリティ担当への相談も急増。黎明期安定期リリース前にも手動診断を行うように。他にも多くのチェックリストが作られる。要件定義設計開発テストリリース運用企画チェックリスト中間評価チェックリスト最終評価手動診断（定期） DASTツール&手動診断～

東京海上日動の開発プロセスにおけるセキュリティ～これまで～ 12 開発プロセスにおけるセキュリティ品質の取組の歴史～2010 セキュリティ専門人材はまだおらず、リリース前に開発者がDASTツールでスキャン。 2011 セキュリティ専門人材が誕生。定期的な脆弱性診断プロセスが開始。公開Webアプリ用のセキュリティ要件とチェックリストが誕生。まだまだセキュリティ担当の関わりは薄い。 2021
散在するチェックリストを束ね、セキュリティチェックリストが誕生。セキュリティ担当が第三者評価するように。開発者はセキュリティを自然と意識しはじめ、セキュリティ担当への相談も急増。黎明期安定期リリース前にも手動診断を行うように。他にも多くのチェックリストが作られる。要件定義設計開発テストリリース運用企画チェックリスト中間評価チェックリスト最終評価手動診断（定期） DASTツール&手動診断～めでたしめでたし・・・では終わらなかった

東京海上日動の開発プロセスにおけるセキュリティ～これまで～ 13 時が経つにつれ、課題が続出多すぎるチェック項目一般的なWebアプリでチェック項目は 150以上。それら全てが要回答・要評価。双方への過負荷現場は案件ごとにチェックリスト作成。
セキュリティ担当は限られた情報で評価。双方工数極大。頭打ちな実効性 YESって回答だけど、本当にできているの？でも信じるしかない。もはや国語の問題と化す要件項目数を減らそうとした結果、Excel のセルに入りきらない要件文。難解すぎて現場は誤答・誤判断頻発。要件定義設計開発テストリリース運用企画チェックリスト中間評価チェックリスト最終評価手動診断（定期） DASTツール&手動診断遅すぎる脆弱性発見リリース直前の脆弱性発見により、手戻り発生。診断手配のリードタイムテンポよく開発したい。すぐリリースしたい。でも診断見積が、契約手続きが、、、

東京海上日動の開発プロセスにおけるセキュリティ～これから～ 14

東京海上日動の開発プロセスにおけるセキュリティ～これから～ 15 セキュリティとは、ビジネスを最大限支援するためのものでなくてはならない。それはシステム開発においても同じ。「辛い・遅い・コスパが悪い」プロセスは見直す必要がある。私たちが目指したい未来 ✓ 低実効性・高負荷なチェックリスト評価型統制からの脱却 ✓ 脆弱性は早期にみつけて素早く潰す。シフトレフト

東京海上日動の開発プロセスにおけるセキュリティ～これから～ 16 ✓ 低実効性・高負荷なチェックリスト評価型統制からの脱却に向けた３つのチャレンジ Before After チェックリストの位置づけ全項目をセキュリティ担当が評価するもの開発者が活用できるリファレンス兼セルフリス
ク評価ツールチェックリストの内容項目数を気にして、難解長大な記述項目数が増えてでも、シンプル明快にリスクと対策を誰もが理解できるように LLMによる高度化も見据えてセキュリティ評価手法セキュリティチェックリスト中心の評価チェックリスト評価はリスクベースで絞りつつ SAST/DASTやポスチャマネジメントでの診断や設定チェック中心の実態評価要件定義設計開発テストリリース運用企画セルフチェック（チェックリスト） SASTツール診断・早期是正各診断結果評価手動診断（定期）ポスチャマネジメントツール診断・早期是正伴走支援手動診断 &DASTツール

High Medium Low High Medium Low YES NO High Medium
Low 東京海上日動の開発プロセスにおけるセキュリティ～これから～ 17 After チェックリストの位置づけ開発者が活用できるリファレンス兼セルフリスク評価ツールリスクベースで本当に必要なところにパワーをかけ、診断結果の実態評価と開発者セルフチェックをメインとしたGuardrail型な“これから” 評価対象システム外部からの攻撃の受けやすさ攻撃成功時の影響度評価対象項目項目の重要度（危険度） × 開発者セルフチェック + セキュリティ担当も評価開発者セルフチェック開発者セルフチェック + セキュリティ担当も評価開発者セルフチェック開発者セルフチェック（診断結果はセキュリティ担当が評価）診断で確認可能な項目か＝ ⚫ リスクベースで注力するセキュリティ担当 ⚫ 裁量と責任の両方を得て、各種診断というガードレールの内側で開発スピードを出せる開発者 ⚫ セキュリティに適正なリソースとスケジュールをかける開発プロジェクト

東京海上日動の開発プロセスにおけるセキュリティ～これから～ 18 After チェックリストの内容項目数が増えてでも、シンプル明快にリスクと対策を誰もが理解できるように LLMによる高度化も見据えてシンプル明快を命題に、一問一答を原則に。セルフチェックメインにするからこそ、「なぜ（リスク）」と「代替策（NOのときどうする）」を丁寧に解説。人間が読み間違えない内容であれば、LLMにも取り込みやすいはず＝LLMによる高度化も目指せるようになるはず。
前提条件目的確認項目満たせない場合の代替策認証機能がある場合辞書攻撃や総当たり攻撃による不正アクセス脅威の低減パスワードは×種×桁以上とする ▪▪▪▪▪する認証機能がある場合パスワード使いまわしの抑制による不正アクセスの低減パスワード変更時、過去×回以内に設定履歴のあるパスワードは拒否する ▪▪▪▪▪する認証機能がある場合辞書攻撃や総当たり攻撃による不正アクセス脅威の低減連続×回の認証エラー時にアカウントロックする ▪▪▪▪▪する・・・ユーザーのパスワードは以下をすべて満たすこと ①パスワードは×種×桁以上とする ②パスワード変更時、過去×回以内に設定履歴のあるパスワードは拒否する ③連続×回の認証エラー時にアカウントロックする ④パスワード設定時、〇〇〇なパスワードは拒否する ⑤パスワードの使いまわしはしないようユーザーに周知するただし、①～③が満たせない場合は、▪▪▪▪▪とすることで代替策としてもよいまた、④、⑤が満たせない場合は、 ▪▪▪▪▪もしくは ▲▲▲とすることで代替策としてもよい分解

東京海上日動の開発プロセスにおけるセキュリティ～これから～ 19 After セキュリティ評価手法 SAST/DASTやポスチャマネジメントでの診断や設定チェック中心の実態評価 SASTとDAST、ポスチャマネジメントで発見された脆弱性は修正済み。再診断で潰し込みも確実。未修正項目は代替策としてこの設定が～
未修正項目についてだけ確認させてほしい。代替策に加えて例えばIP制限って～～真に必要な数回のやりとりを経て～診断で致命的なものはでてないし、未修正も判断根拠十分。承認！検出ベースだから話もスムーズだったな、次工程にもすぐ移れるぞ！アウトプット：品質根拠のあるセキュリティチェック結果評価の根拠：診断結果と設定値疲労感：必要最小限。納得感もある

東京海上日動の開発プロセスにおけるセキュリティ～これから～ 20 ✓ 脆弱性は早期にみつけて素早く潰す。シフトレフトに向けた２つのチャレンジ Before After セキュリティ担当の関与相談が来たら対応。QA型高難度案件は、要件定義・設計段階から
伴走支援脆弱性診断の方法リリース直前にDAST(ツール＋手動)のみ SAST＋DASTの2段構え要件定義設計開発テストリリース運用企画セルフチェック（チェックリスト） SASTツール診断・早期是正各診断結果評価手動診断（定期）ポスチャマネジメントツール診断・早期是正伴走支援手動診断 &DASTツール

東京海上日動の開発プロセスにおけるセキュリティ～これから～ 21 After セキュリティ担当の関与高難度案件は、要件定義・設計段階から伴走支援高難度案件・重要案件にプロジェクトチームの一員として深く入り、脆弱性をそもそも作りこませないことにパワーをかける“伴走支援” とあるアジャイル開発で伴走支援を試行してみた例。結果として、Day8で検出された脆弱性は非常に軽微かつ数も少なく、手戻りは発生しなかった。 Day1
Day2 ～ Day7 Day8 Day9 Day10 開発チームスプリントプランニング設計開発テスト脆弱性修正レトロスペクティブセキュリティ担当システム理解要件理解セキュリティレビュー計画・テスト計画セキュリティ設計レビューセキュアコーディングレビュー SAST / DAST ⇒ 修正支援ブラックボックステスト（全機能DAST）脆弱性修正支援

東京海上日動の開発プロセスにおけるセキュリティ～これから～ 22 After 脆弱性診断の手法 SAST＋DASTの2段構え SASTで見つけられる脆弱性をDASTまで残存させないことで、開発後期の脆弱性発見＝大きな手戻りの可能性を減らす書いたコードでこう検出された、という経験の繰り返しが現場のセキュアコーディングスキル向上に寄与開発テスト資源開発するたびに自動SASTツール診断＆すぐ是正
SASTでしか検出できない脆弱性 DASTでしか検出できない脆弱性両方で検出できる脆弱性リリースツール＆手動診断

まとめ 23

まとめ 24 ⚫ 多層防御技術に実効性を持たせるのは、開発プロセスである ⚫ ただし、レガシーなチェックリスト統制では、かかる負担に対して効果が見合わない ⚫ 全てが高速化する今の世の中、シフトレフトなプロセスへと改善することが急務 ⚫ プロセス上のGatewayは最小限に、可能な限りGuardrail型へ

ありがとうございました

東京海上日動におけるセキュアな開発プロセスの取り組み

東京海上日動におけるセキュアな開発プロセスの取り組み

miyabit

Other Decks in Technology

Featured

Transcript