2025年新卒として開発本部に配属されました、恩智太陽です。
早速ですが若手エンジニアの皆さん、セキュリティを意識してコーディングできていますか？
私はセーフィーに入るまでほぼ意識せずWebアプリ開発など行っていました…
IT業界においてセキュリティは理系、文系どちらに行っても切っても切り離せない英語のような重要な存在です。
そんなセキュリティの学習をおろそかにしてしまうと、どんなにいいサービスを作ったとしても、悪意のある人の手によって台無しにされてしまうことがあります。
それぐらいとても重要な分野ですが、セーフィーでは新卒研修の一環として座学＋ワークショップ＋ハンズオン形式で実施するセキュリティ研修があります。
この記事の前半では研修で何を学んだのかについて、後半では学んだことをどのように業務でアウトプットしたのかをご紹介します。
- はじめに
- 座学：アジャイルと脅威モデリングについて
- ワークショップ：脅威モデリングを実践！
- 脆弱性診断ハンズオン：ハッカーになって攻撃してみた
- アウトプット：セキュリティ研修で得た知識を実践へ！
- まとめ
はじめに
この記事で伝えたいこと
- セーフィーのセキュリティ研修の概要について
- 学んだことをどのように仕事に生かしたのか
誰向けの記事？
- セキュリティの重要性をあまり認識していない方（開発者）
- 攻撃手法の概要は把握しているが、具体的な攻撃のイメージがついていない方
- どんなところに脆弱性が潜んでいるのかイメージできない方
座学：アジャイルと脅威モデリングについて
研修の前半では、まずアジャイル開発について学び、その後に脅威モデリングを学びました。
私自身、「アジャイル開発」というものは知っていたのですが、「なぜセキュリティの研修なのに、なぜアジャイル開発の話から始まるんだろう？」というのが正直な感想でした。
それは、アジャイル開発の強みである「スピード」が、セキュリティ対策の遅れで弱点に変わるからです。開発終盤での設計の修正は、多大な手戻りとコストがかかってしまいます。
そこで重要なのが、セキュリティ対策を開発初期から行う「シフトレフト」という考え方です。
開発のスピードと安全性を両立させるためには、まずその土台となるアジャイル開発の全体像を理解することが不可欠だったのだと、深く納得しました。
※「設計段階(青)」で不具合を見つけて修正するコストを基準の1とした時、「開発段階(橙)」、「テスト段階(灰)」、「リリース段階(黄)」それぞれで対応した時のコストのかかり方
脅威モデリングとは、システムに対して「どのように攻撃が発生しうるか」を体系的に分析し、具体的な攻撃経路やリスクを特定するためのリスク分析手法であり、シフトレフトを実践するための強力なプラクティス（実践手法）の一つです。
この手法の強みは、設計段階で潜在的な問題を早期に発見・修正できるため、後の工程での修正コストを最小限に抑えることができるということに加え、「チーム内の共通理解を形成できること」があります。
DFD（データフロー図）のようなモデルを使うことで、チーム全員が同じ図を見て同じ目線で「システムがどのように攻撃されうるか」を議論できるようになります。
研修を受ける前の私は、正直なところ「セキュリティ対策＝実装段階でのコーディングにて対策」というイメージでした。
しかし、この研修を通してシステムの設計そのものに脆弱性が潜む可能性や、チーム全体で脅威について対話し、共通認識を持つことの重要性を学びました。
セキュリティは専門家だけの閉じた仕事ではなく、開発に関わる全員で対話し、作り上げていくことが重要だと、セキュリティに対する考え方が大きく変わる経験となりました。
ワークショップ：脅威モデリングを実践！
座学の後は、チームに分かれて脅威モデリングのワークショップを体験しました。
課題は、タスク管理Webアプリ（脆弱性診断ハンズオンで用いる「Bad Todo List」）の要件をベースに、どのような脆弱性があるのかを、脅威モデリングの「4つの問い」に沿って考えていくというものでした。
ワークショップの流れについては「セーフィーの脅威モデリングベースのセキュア開発トレーニング」の記事をご確認ください。
4つの問いに対して行ったこと
ステップ1：DFDで「私たちは何に取り組んでいるか？」を明確にする
脅威モデリングの最初の問い、「私たちは何に取り組んでいるか？」を明確にするため、今回は一般的に使われる「DFD (データフローダイヤグラム)」を用いてシステムの全体像を分析しました。
DFDは、システムにおけるデータの「流れ」と「処理」を視覚的に表現する図で、詳細な動作(How)よりも「何をするのか(What)」を明らかにすることに長けています。
DFDの矢印はあくまでデータの流れ（Data Flow）のみを記述しなければならず、書き始めはこのルールになかなか慣れませんでした。
つい「データを取得するリクエスト」のような、処理の制御に関する矢印を何度も書きそうになり、苦労しました。
ですが、Bad Todo Listの要件から上記のようなDFDを作成していくと、要件を見ただけでは気づけなかった視点や懸念点が次々と浮かび上がってきました。
ステップ2：STRIDEで「何が問題になりうるか？」を洗い出す
次に、「何が問題になりうるか？」という問いに答えるため、「STRIDE」というフレームワークを使って「起きたら困ること（リスク）」を洗い出しました。
STRIDEは、以下の6つの観点から脅威を分類する「型」です。
このフレームワークを用いることで、攻撃者の動機や目的といった、より高い視点から体系的に脅威を分析することができます。
作成したDFDの各機能やデータの流れに対して、
「ユーザー情報登録の際に、大量の登録リクエストが送られてくると、データベースが破壊される可能性があるからD(サービス拒否)が当てはまる」
「タスクの編集の際に、タスクを勝手に書き換えられたり、消されたりする可能性があるからS(なりすまし)とT(改ざん)が当てはまる」
などとSTRIDEの観点を当てはめていくことで、具体的なリスクを次々と見つけることができました。
私が作ってきたアプリも世の中に公開した場合、こんな風に攻撃者の視点で見られていたのかもしれないと思うと、少しぞっとしました。
ステップ3 ：リスクマップで優先順位をつけて対策を考える
多くのリスクを洗い出すと、次に「では、それに対して何をするのか？」を考えます。
しかし、すべてを一度に対策しようとすると、本当に危険なリスクへの対応が遅れてしまう可能性があります。
そこで、「リスクマップ」を使い、対策の優先順位を決めました。
これは、「リスク＝発生確率 × 影響度」という考え方に基づき、「発生しやすさ」と「発生した場合の被害の大きさ」で評価し、優先順位をつけていく手法です。
今回の要件では、タスクの情報などを保存するデータベースに関する攻撃が一番「影響度」が高く、「発生確率」に関しても攻撃しやすい箇所であると考えました。
よって、「データベースに大量の登録処理が行われ、データベースが破壊される」というリスクを「発生確率」「影響度」ともに5と設定し、一番優先度が高いものとしました。
このステップを通して、やみくもにすべてのリスクに対策するのではなく、最も危険なリスクから対処するという、現実的かつ合理的な手法を学びました。
ステップ4：＋／Δ (プラス／デルタ)で振り返える
各スプリントの最後には、「＋／Δ (プラス／デルタ)」という手法で振り返りを行いました。
これは、活動の良かった点（プラス）と改善点（デルタ）を出し合う手法です。
最初のスプリントで、私たちはタスクの「追加」「編集」「削除」をそれぞれ別のプロセスとしてDFDに書き出しました。しかし、結果的に3つのプロセスに繋がるデータの流れは、ほぼ同じ内容になってしまったのです。
この結果から、私たちは「プロセスの粒度をきちんと決めずに書き始めてしまった」という改善点（デルタ）を見つけ出しました。
この気づきを元に、次のスプリントではまず「データの流れが同じ処理は、一つのプロセスにまとめよう」と決めました。
その結果、DFDの粒度が統一されてプロセスが整理されただけでなく、同じリスクに対する付箋も一つに集約でき、格段に見やすい図に改善することができたのです。
この振り返りがあったことで、今回のスプリントで良かったことは引き続き継続し、改善点は次回のスプリントで意識して行動することができたため、アジャイル開発ととても相性のいい手法だと感じました。
完成後にチームごとに発表
ワークショップの最後にチームごとに作成したDFDをそれぞれ発表しました。
プロセスの粒度の違い、ユーザー権限ごとに表を分けて分析していたりなど、考え方の違いや、ホワイトボード、付箋の使い方が各チームそれぞれ個性があり、全く系統の違うDFDが完成していたので非常に面白かったです。
チームによってアプローチが異なり、多様な視点に触れることができました。
このワークショップで感じたこと
この一連のワークショップを通して、脅威モデリングを行う上で便利なワークフローが多く存在し、それを用いることによって最初からでは気づけなかった脆弱性やリスクの大きさに気づくことができたため、ワークフローの有用性を改めて感じました。
一方で、「フレームワーク通りにやれば安心」という「罠」に陥ってはいけない、という講師の金原さんの言葉が印象に残っています。
最も重要なのは、フレームワークを参考にしつつも、チームや顧客との対話を続け、学び、改善し続けることなのだと実感しました。
脆弱性診断ハンズオン：ハッカーになって攻撃してみた
研修の最後に、実際に脆弱なWebアプリケーション（やられアプリ）に対して攻撃を仕掛けるハンズオンを行いました。
ローカルプロキシ「Burp Suite Community Edition」を使い、ハッカーが実際に脆弱性をどのように見つけ、どのように攻撃するのかを体験しました。
ここでは、代表的な攻撃であるSQLインジェクションをどのように体験したかを紹介します。
SQLインジェクションは、アプリケーションが想定しないSQL文を意図的に実行させ、データベースを不正に操作する攻撃です。
今回は先のワークショップでリスク分析をした「Bad Todo List」という脆弱性を持ったアプリケーションで体験しました。
注意⚠️ 本記事で紹介している内容はあくまで学習目的で、特別な許可のもと安全な環境下で実施したものです。
許可なく第三者のウェブサイトやシステムに対して、脆弱性を試すような行為を行うことは法律で固く禁じられておりますので、ご注意ください。
サイトにアクセスしてみると、以下のようなごく普通のTodoアプリの画面が表示されますが、このサイトにはいたるところに脆弱性が潜んでいます。
データベースの情報を抜き取ってみる
脆弱性のある入力フォームに「パソコン' OR 'a'='a」と入力してみます。
これを入力すると、プログラムの内部ではSQL文が次のように組み立てられます。
...AND todo LIKE 'パソコン' OR 'a'='a';
この命令文は、データベースに対して「Todoに『パソコン』と書かれている」または(OR)「『a』と『a』は等しい」という条件でデータを要求します。
「'a'='a'」は常に真（true）なので、結果として「すべての条件を無視して、データベースにある情報をすべて表示しろ」という命令に変わってしまうのです。
その結果、以下の画像のように、公開、非公開の設定（画像右側）に関係なくすべてのデータベースの情報が表示され、見えてはいけない重要な情報が見えてしまいます。恐ろしい…
SQLインジェクションの本当の恐ろしさ
表示されている情報をすべて抜き取れるだけでも十分に恐ろしいですが、SQLインジェクションの危険性はこれだけではすみません。
攻撃者は、この脆弱性を利用してさらに悪質な攻撃を仕掛けることができます。
個人情報の窃取
UNIONといった特殊な命令を組み合わせることで、Todoリストだけでなく、システムに登録されている全ユーザーのID、メールアドレス、さらにはパスワード情報まで盗み取ることが可能です。データの改ざんと削除 情報を盗むだけでなく、データベース内の情報を自由に書き換えたり、全てのデータを削除したりすることもできてしまいます。
- サーバーの乗っ取り データベースの設定によっては、SQLインジェクションを足がかりに、最終的にWebサーバーそのものを乗っ取られてしまうケースさえあります。
このように、たった一つの入力欄の不備から、システム全体を揺るがす甚大な被害に繋がりかねないのが、SQLインジェクションの本当の恐ろしさなのです。
脆弱性診断ハンズオンで感じたこと
このような形で様々な攻撃手法を実践的に学びました。
SQLインジェクションだけでも深刻な被害につながるのに、Webアプリケーションには他にも無数の攻撃経路が潜んでいるという事実に、「一体どうすればこんな攻撃を思いつくのか」と、その発想力に圧倒されるばかりでした。
これまでは「どうすれば動くか」という「作る側」の視点でしかコードを見ていませんでしたが、この研修では「どうすれば壊せるか」という「攻撃される側」の視点を初めて得ることができました。
アウトプット：セキュリティ研修で得た知識を実践へ！
ここからは、セキュリティ研修後に私がどのようなアウトプットを行ったかを紹介します。
新卒研修プロジェクトに取り入れる
現在、私たち新卒エンジニアは社内の課題を解決するシステムを開発するという研修に取り組んでいるのですが、そこで今回のワークショップやハンズオンで学んだ対策を盛り込みました。
①設計の土台である非機能要件に反映
まず、プロジェクトの設計の土台となる非機能要件に、今回の研修で学んだ攻撃手法から実際に作るシステムでどんな脆弱性が考えられるかを洗い出し、それに対する対策を具体的に定義しました。
| 分類 | 項目 | 対策内容 |
|---|---|---|
| アクセス・利用制限 | アプリケーションレベルのアクセス制限 | SlackOAuthを通して、許可された利用者（@safie.jpアカウント）のみがシステムを利用できること。 |
| アクセス・利用制限 | 安全な認証・セッション管理 | JWTを利用し、サーバー側で電子署名を検証することでデータの完全性を担保する。 |
| 脆弱性対策 | SQLインジェクション対策 | DBへの問い合わせはプレースホルダを用い、不正なSQL実行を防御する。 |
| 脆弱性対策 | クロスサイトスクリプティング（XSS）対策 | ユーザー入力値をWebページに表示する際は、適切にエスケープ処理を行う。 |
| 脆弱性対策 | クロスサイトリクエストフォージェリ（CSRF）対策 | トークンを用いて、意図したユーザーからのリクエストであることを検証する。 |
このように開発の初期段階からセキュリティを要件として定義することで、後工程での手戻りを防ぎ、まさにセキュリティ研修で学んだ「シフトレフト」の考え方を実践することができました。
②作った機能に「攻撃」を仕掛けてみる
次に、定義した非機能要件の一つ、「アプリケーションレベルのアクセス制限」を実装し、実際にテストを行いました。
この機能は、許可されたドメイン（@safie.jp）以外のアカウントではログインできないようにするものです。
研修でお世話になった講師の金原さんに協力をお願いし、脆弱性診断で使った「Burp Suite」を用いて、外部のメールアドレスでログインを試みる擬似的な攻撃を仕掛けてもらいました。
「本当に防げているのだろうか？」という漠然とした不安が、Burp Suiteの画面でどのようなリクエストが飛んできて、どのようにデータが処理され、どのように外部からのメールアドレスがはじかれているかを可視化でき、設計したセキュリティ機能に自信を持つことができました。
まとめ
今回のセキュリティ研修では、座学でのインプットだけでなく、脅威モデリングワークショップや脆弱性診断ハンズオンといった実践的な演習を通して、セキュリティの知識を深く理解することができました。
特に、実際に手を動かして攻撃者の視点を体験したことで、これまで漠然としていた脅威が、具体的なイメージ（勘所）として掴めるようになったのが一番の収穫だと感じています。
この研修で得た学びを活かし、今後の開発業務では開発初期段階から常にセキュリティを意識し、安全なプロダクト作りに貢献していきたいと思います。
25年度新卒研修に関する記事はこちらをご覧ください。
