はじめに
前回の記事では、フロントエンドの診断だけでは埋まらない守りの層がいくつもある、という話を書きました。今回は、その層に回す人と時間を誰が決めるのか、という話です。
先日、機微なデータを扱う業種の方と、セキュリティの話をする機会がありました。
※免許証ではありません。日本ではこれを元にクレジットカードが作れてしまう最上位のものですが、種類が異なります。
聞くと、いまはみなで通常の業務を最低限に絞って、全力でセキュリティ対策に当たっているそうです。
そういう業種なのだから当然だろう、とは思います。それでも現職で感じてる「自分ならこうするのに」と思っていたことを実際にやっている会社があると知って胸がスカッとしました。
いちばん大きいと感じたのは、それを経営が決めているという点です。
業務を絞ると決められるのは、経営だけ
通常の業務を絞るということは、売上や開発の予定を後ろにずらすということです。現場のエンジニアがどれだけ危機感を持っていても、この判断は現場ではできません。
経済産業省と IPA の「サイバーセキュリティ経営ガイドライン Ver3.0」も、経営者が認識すべき 3 原則の一つ目に、経営者が「自らのリーダーシップのもとで対策を進めること」を挙げています。新たな脅威に対処するための予算措置などの経営判断も求められ、「担当者への丸投げは許されるものではない」とまで書かれています。
前回も書いたとおり、攻める側は穴を一つ見つければ足ります。守る側は、すべての入り口とその内側を守らなければなりません。
守りに回す人と時間は、ほかの仕事と取り合いになります。その天秤で守りを取ると決めるのは、経営の仕事です。話を聞いた会社では経営がそれを決めていました。
当然のことは、当然には起きない
機微なデータを扱うのだから当然だ、と言うのは簡単です。しかし、当然やるべきことが、当然のように行われているとは限りません。売上や納期と比べれば、守りはいつでも後回しにできてしまうからです。
話を聞いた知人のなかには、上場を控えているのに漏洩対策が本気とは思えない企業もありました。
上場の 1〜2 年前は、ちょうど上場の審査で振り返られる期間に当たります。東証の「新規上場ガイドブック（グロース市場編）」は、審査の基準の一つに、法令を守る体制が整って運用されていることと、「最近において重大な法令違反を犯しておらず」を挙げています。申請会社に説明を求める項目にも、「最近３年間及び申請期」の法令違反や、関係官庁による行政指導・処分の内容、その後の再発防止の体制があります。
一定の漏洩が起きれば、個人情報保護委員会への報告と本人への通知が必要になります（個人情報保護法第26条）。安全管理措置（同第23条）が足りていたかも問われます。上場を目指す会社なら、その経緯と再発防止の体制を、審査で説明することになると思います。
上場の承認を受けた後でも安心はできません。同じガイドブックは、上場適格性に疑義が生じた場合、原則として上場承認を取り消して確認を行う、としています。実際に 2016 年、ZMP は東証マザーズへの上場承認を受けた直後に、顧客リストの一部がネット上に流出したと発表しました。上場は延期され、東証も承認を取り消しています。1 年半ほど後の 2018 年 4 月の時点でも、再申請はしていないと報じられました。
上場の前は、売上や納期に追われる時期でもあります。しかし、その時期の漏洩は上場そのものを止めることがあります。
流出したら「それはあかんだろう」と誰もが怒るデータがあります。運転免許証は数ある情報漏洩の中でも別格の扱いをうけて然るべきですが、業種に限らずそういった情報をどの組織でもどこかに持っている可能性があります。
自分の現場のデータを、一度この物差しで見てみてください。
お金にならない情報でも、漏れてほしくない人がいる
最近、ある機関に証明書の発行を頼みました。企業と比べれば、お金になる情報は持っていない機関です。攻撃するほどの価値はない部類で、そういう意味では防壁というよりお堀が深い、とでも言えるかもしれません。
しかし持ち主にとっては、漏れてほしくない事に変わりはありません。それに、攻撃はお金目当てとは限りません。IPA は「情報セキュリティ10大脅威 2026」で、AI の悪用によるサイバー攻撃の容易化を挙げています。敷居が下がれば、より些細な理由での嫌がらせも増えうると思います。
件の発行依頼の申し込みの画面では、クレジットカードの番号をそのまま入力させるようになっていました。いまどきそれはいかがなものか、と思いました。カードには本人認証の仕組みもありますが、それでも番号が漏れるのは嫌なものです。
経済産業省の資料によれば、業者がカード番号を保存していなくても、入力する画面が改ざんされれば番号は抜かれます。割賦販売法は、カード番号を適切に管理する義務を、カードで代金を受け取る販売業者や役務提供事業者に課しています。会社に限った話ではありません。
カード番号を入力しない払い方も選べたので、私はそちらを選びました。Apple Pay のように、カードの番号全体が店に渡らない払い方もあります。
使う側は、番号を入力しない払い方を選べるなら選ぶ。支払いを作る側は、番号を入力させない払い方を用意するか、入力させるなら画面の改ざん対策まで自分の持ち場に入れる。どちらにも言えることだと思います。
おわりに
胸がスカッとしたのは、それが特別な話ではなく、本来はどこでもやるべきことだと思っているからです。
前回の記事では、次の表の右の列を自分の現場で埋めてみてください、と書きました。
層 守れていないと何が起きるか あなたの現場で見ている人 フロントエンドと公開 API（外から） 外から直接攻撃される アカウントと認証情報 正規の利用者として入られる 実装の権限チェック ログインした人が他人のデータを読み書きできる 依存パッケージ・ミドルウェア・OS 既知の脆弱性を突かれる 取られた権限の範囲 一つのアカウントから全体に広がる 侵入に気づく仕組みとログ 入られたことに気づけず、後から追えない 公開範囲を広げる変更 設定一つで、閉じていたものが外に開く 消されたときの復旧 バックアップごと消されて戻せない
右の列が空いたままの行があったかもしれません。その行に回す人と時間をどこから持ってくるかは、経営が決めることです。業務を絞ってでも守ると決めた会社が実際にある、という事実は、その話を上に持ち込むときの後押しになると思います。
興味のある方の参考になれば幸いです。私はセキュリティの専門家ではないので、誤りや足りない点があれば、ご指摘を歓迎します。
参考文献
- え？フロントエンドだけですか？（前回の記事） https://qiita.com/dkuro/items/e0e9e6d55f0db944e663
- DB を消せる権限で、バックアップも消せませんか https://qiita.com/dkuro/items/90d809c03ca0c114db7f
- 経済産業省・IPA「サイバーセキュリティ経営ガイドライン Ver3.0」（2023 年 3 月）p.3–4 https://www.meti.go.jp/policy/netsecurity/downloadfiles/guide_v3.0.pdf
- 東京証券取引所「2024 新規上場ガイドブック（グロース市場編）」（2026 年 9 月 15 日更新版）p.21（Q3）、p.50、p.77、p.114 https://www.jpx.co.jp/equities/listing-on-tse/new/guide-new/02.html
- 個人情報の保護に関する法律 第23条・第26条（e-Gov 法令検索） https://laws.e-gov.go.jp/law/415AC0000000057
- 日本経済新聞「ZMP、顧客情報流出で上場延期 「厳粛に受け止める」」（2016 年 12 月 8 日） https://www.nikkei.com/article/DGXLASDZ08HZ6_Y6A201C1TI1000/
- ITmedia NEWS（2018 年 4 月 19 日） https://www.itmedia.co.jp/news/article/1804/19/1180419115/
- IPA「情報セキュリティ10大脅威 2026」 https://www.ipa.go.jp/security/10threats/10threats2026.html
- 経済産業省「最近の主な漏えい事案」（2022 年 8 月） https://www.meti.go.jp/shingikai/mono_info_service/credit_card_payment/pdf/001_04_02.pdf
- 割賦販売法 第35条の16（e-Gov 法令検索） https://laws.e-gov.go.jp/law/336AC0000000159
- Apple「Apple Payを使ってカードで支払う」 https://support.apple.com/ja-jp/guide/security/secfbd5c0e54/