セキュリティ要求は、待ってくれない を公開

source/_posts/2026/20261026a_秋のブログ週間2026.md

@@ -36,10 +36,11 @@ lede: "秋のブログ週間とは2020年から始まったブログリレーの
 | {% thumb 20261030a %} 10/30 金 | 山田 勇一  | [非機能はなぜ必要なのか](/articles/20261030a/) |
 | 2週目     | 🍂     |                                      |
 | {% thumb 20261102a %} 11/2 月 | 山田 勇一  | [サービスレベル設計として捉える非機能の考え方](/articles/20261102a/) |
-| 11/4 水  | 棚井 龍之介 | 調整中 |
-| 11/5 木  | 内堀 航輝  | 調整中 |
-| 11/6 金  | 高嶋 ありさ | 調整中 |
+| {% thumb 20261104a %} 11/4 水 | 山田 勇一  | [セキュリティ要求は、待ってくれない](/articles/20261104a/) |
+| 11/5 木  | 棚井 龍之介 | 調整中 |
+| 11/6 金  | 内堀 航輝  | 調整中 |
 | 3週目     | 🌰     |                                      |
-| 11/9 月  | 真野 隼記  | 調整中 |
+| 11/9 月  | 高嶋 ありさ | 調整中 |
+| 11/10 火  | 真野 隼記  | 調整中 |
 
 いつもはコードが本文に書かれていることも多いフューチャー技術ブログですが、この連載はスマホ片手で読めるような記事成分を高めたいと思います。約2週間、どうぞお付き合いください。

source/_posts/2026/20261104a_セキュリティ要求は、待ってくれない.md

@@ -0,0 +1,131 @@
+---
+title: "セキュリティ要求は、待ってくれない"
+date: 2026/11/04 00:00:00
+postid: a
+tags:
+  - 非機能
+  - 要件定義
+  - 脆弱性
+categories:
+  - Security
+series: "秋のブログ週間2026"
+thumbnail: /images/2026/20261104a/thumbnail.png
+author: 山田勇一
+lede: "相次ぐ不正アクセスの報道と、それに対する「指摘を放置していた」という反応を、非機能の観点から考えます。セキュリティの要求水準は自分たちの事業が変わらなくても攻撃者の側の変化で上がるという特性を踏まえ、自分たちのセキュリティ要求を見直すための考え方を整理します。"
+---
+[秋のブログ週間2026](/articles/20261026a/) の6本目です。
+
+<img src="/images/2026/20261104a/top.png" alt="" width="1200" height="630">
+
+## はじめに
+
+前回の記事「[非機能はなぜ必要なのか](/articles/20261030a/)」では、非機能要件はほとんどサービスレベル設計と同じものであり、利用者への約束として事業者が決めるものであり、「事業が変わったら約束そのものを見直す」ところまで含めて保証だと書きました。
+
+この秋、国内では不正アクセスによる被害が相次いでいます。先日も、ある大手インターネット企業が不正アクセスの問題で記者会見を開きました。
+
+私はセキュリティの専門家ではなく、本職の外にいる一人の技術者です。それでも、一連の報道とそれに対する反応を見ていて、非機能の観点から思うところがありました。短絡的に感じる意見も多く、少し怖くなったというのが正直なところで、自分の考えをまとめてみます。
+
+なお、特定の企業を評価したり批判したりする意図はありません。報道から読み取れる範囲の話として読んでいただければと思います。
+
+## 報道から読み取れること
+
+報道によると、その企業が提供するサービスに不正アクセスがあり、利用者の情報が盗まれ、金銭的な被害も出ているそうです。
+
+そして、数年前にグループ内の専門家からこのサービスの脆弱性を指摘されていたことも明らかになりました。指摘を受けて対策は施したものの、結果として十分ではなかった、と報じられています。
+
+## 世の中の反応
+
+SNS やニュースのコメント欄を眺めていると、次のような意見を見かけます。
+
+- 「結局のところ、セキュリティ体制が甘かったからでしょ」
+- 「何年も前に指摘されていたのに放置していたなんて、人災だよね」
+- 「もっと高度なセキュリティ体制をとっておけばよかったのに」
+- 「定期的に見直すべきだよね」
+
+結果だけを見れば、どれも正しいと思います。実際に被害に遭われた方がいて、事業者に責任がないとは思いません。
+
+ただ、「指摘を放置していた」という言い方には、少し違和感があります。報道を見る限り、指摘を受けて対策は施されていました。足りなかったのは事実だとしても、何もしなかったわけではなさそうです。
+
+そして、こうした意見の多くは「あの会社がダメだった」で話が閉じているように見えます。読んだ人が、自分の組織やシステムに当てはめて考える余地がありません。私が怖いと感じたのはそこです。
+
+## 企業は、無限には投資できない
+
+前回の記事の続きとして、まず前提を確認させてください。
+
+非機能の水準は、コストを決めます。可用性を上げれば冗長化の費用がかかり、性能を上げればインフラの費用がかかります。セキュリティも同じで、対策を厚くするほど人・物・金が必要になります。そして、企業は無限には投資できません。どこに、どれだけ投資するかを選ぶ必要があります。前回、サービスレベルは事業者が判断して決めるものだと書いたのは、この選択のことです。
+
+脆弱性を指摘されたとき、どの企業も次の選択をします。
+
+- サービスを止めて抜本的に作り直すのか、止めずに対策を施すのか
+- どこまで投資するのか
+
+その選択の軸になるのは、その時点の社会情勢に基づく非機能の判断です。その時点の脅威の水準、攻撃の頻度、世の中の被害の状況を見て、「この対策で見合う」と判断する。数年前の判断も、当時としては筋の通ったものだった可能性があります。
+
+あとから結果を見て「指摘を放置していた」と言うのは簡単です。でも、それは今の物差しで、過去の判断を裁いていることになるのではないでしょうか。
+
+## 要求が変わる速さに、追いつけない
+
+こうした事案の本質の1つは、セキュリティへの要求が外部の要因によって急速に変わり、その変化に追従するための人・物・金を投入しきれないことにあると考えています。
+
+ここ数年で、前提は大きく変わりました。生成 AI の急速な発展で、攻撃に必要な知識や手間は大きく下がったと言われており、実際に攻撃の数も増えています。この秋は政府が緊急対策をまとめる事態になり、AI が自動で脆弱性を突く攻撃への対策を求める声も上がっています。
+
+数年前に「これで十分」と判断した水準が、今は十分ではなくなっていると言うことが、どの組織でも起こりうる状況だと思います。
+
+そして、ここまで急速な変化についていけている組織は、圧倒的に少数だと思います。もしかすると、ほとんど存在しないのかもしれません。
+
+## セキュリティは、自分たちの都合で要求が変わらない
+
+前回の記事では、「事業が変わったら、約束そのものを見直す」と書きました。一連の報道を見て、この書き方では足りなかったと感じています。
+
+性能や可用性の要求は、基本的に自分たちの事業から生まれます。利用者が増えた、業務イベントが増えた、提供時間を延ばしたい。どれも事業の側に変化の起点があり、ある程度は自分たちで見通せます。
+
+ところが、セキュリティの要求水準は、自分たちの事業が何も変わらなくても上がります。変化の起点が攻撃者の側にあるからです。サービスの内容も、利用者も、システムも同じなのに、昨日まで十分だった約束が今日は守れなくなる。非機能の中でも、セキュリティはそういう特殊な項目だと改めて認識しました。
+
+「定期的に見直すべきだ」という意見は、そのとおりです。ただ、年に一度の棚卸し（あくまで私の感覚ですが、一般的にはこのくらいの頻度だと思います）では、この速さに間に合わないかもしれません。そして、見直した結果として人・物・金を投入できなければ、見直しは「課題があることを知っている」状態を作るだけです。
+
+## 「止める」も、事業者の判断である
+
+報道の中には、「サービスを一時的に止めてでも対応すべきだった」という声もありました。
+
+これは、可用性とセキュリティのどちらを優先するか、という判断です。止めれば利用者は使えなくなり、売上も止まります。止めなければ、利用者を危険にさらし続けるかもしれません。どちらを選ぶかは技術の判断ではなく、事業の判断です。
+
+専門家から脆弱性を指摘されて、稼いでいるサービスをすぐに止められる組織がどれだけあるでしょうか。多くの組織は、止めずに対策を施すほうを選ぶと思います。だからこそ、事が起きてから判断するのではなく、「どういう状況になったら止めるのか」を、平時のうちにサービスレベルの一部として合意しておく必要があるのだと思います。
+
+## もっと手薄なシステムは、たくさんある
+
+これは個人の所感ですが、日本企業はセキュリティにお金をかけない傾向があると感じています。
+
+今回報道された企業は、グループ内にセキュリティの専門家を抱え、脆弱性を指摘できる体制を持っていました。指摘を生かしきれなかったことは問題ですが、そもそも指摘できる体制があったとも言えます。
+
+世の中には、それよりもコストをかけず、体制も薄く、技術的にも貧弱なシステムが数多くあると思います。脆弱性診断をリリース以降受けていないシステムもあるかもしれません。そうしたシステムが今まで無事だったのは、守りが固かったからではなく、たまたま狙われなかったからかもしれません。
+
+次に運が悪いのは、自分たちかもしれません。
+
+## 自分たちのセキュリティ要求を見直す
+
+では、何をすればよいのか。前回の記事の考え方に沿って、今の私の考えを書きます。
+
+1. **セキュリティの約束を業務の言葉で書き直す**
+    「安心して使えるか」という利用者の問いに対して、何が漏れたら、何を乗っ取られたら、利用者に何が起きるのかを書き出します。たとえば、金融取引に使われるサービスでログイン情報が盗まれれば、利用者の資産が直接失われます。それが分かっていれば、求められる水準も、止める判断の重さも変わってきます。
+2. **選択の根拠を残す**
+    「どの程度の攻撃者を想定して、どこまで投資すると決めたのか」を、判断した時点の社会情勢とセットで残します。前提が残っていれば、数年後の状況と見比べて「前提が崩れた」と気づけます。根拠のない「対策済み」は、いつまでも対策済みのまま残ります。
+3. **見直しのきっかけを、定期だけでなく外部の変化にも置く**
+    たとえば次のような出来事です。
+    - 重大な脆弱性の公表
+    - 同業他社の被害
+    - 攻撃手法の変化
+
+    この秋のように被害が相次いでいる状況は、まさにその合図です。自分たちの事業が変わっていなくても、こうした出来事をきっかけに、前回の選択がまだ妥当かを確かめます。
+4. **止める判断の基準と、その判断をする人を先に決めておく**
+5. **見直しを予算とセットで扱う**
+    企業は無限には投資できないからこそ、セキュリティ要求の見直しは、人・物・金の配分の見直しでもあります。お金を出す人が判断に加わらなければ、見直しは机上の作業で終わってしまいます。
+
+## おわりに
+
+被害に遭われた方がいる以上、事業者の責任は重いものです。そこを軽く扱うつもりはありません。
+
+それでも、どこか一社を悪者にして終わってしまうことが、一番怖いと思っています。「指摘を放置していた」「あそこは甘かった」と言うのは簡単です。でも、その言葉を自分たちのシステムに向けたとき、胸を張れる組織がどれだけあるでしょうか。数年前の自分たちの判断を、今の物差しで説明できるでしょうか。
+
+大事なのは、一連の出来事を教訓に、各自が自分たちのセキュリティ要求を見直すことだと思います。前回、非機能を考えるときはシステムの前にサービスを見たいと書きました。セキュリティについては、サービスの外にいる攻撃者まで見なければいけないのだと、改めて感じています。
+
+今回も勢いで書きました。セキュリティは本職ではないので、誤った理解があればご意見をいただけたら嬉しいです。