ウェブサイトとアプリの不正アクセス対策｜政府文書を経営者向けに解説

こんにちは、株式会社TIMEWELLの濱本です。

昨日の2026年11月5日、内閣官房の国家サイバー統括室が、事業者向けの文書を公表しました。題は「個人情報の漏えい等につながる不正アクセスへの対策について」で、副題には「ウェブサイトやモバイルアプリに関する基本的な対策の徹底」とあります。全体で13ページ。最後の2ページは参考資料の一覧なので、本文は11ページです¹。

読み通した私の感想は、内容はとても的確で、ただし初めて読む経営者の方には、ほとんど暗号に見えるだろうというものでした。たった1ページの中に「SBOM」「アタックサーフェス」「BOLA」「SSRF」「SOAR」と、アルファベットの略語が次々に現れます。専門の担当者が読めば「必要なことがすべて書いてある」と感じる資料ですが、そうでない人には、何をすればよいのかが見えません。

そこで、この記事では13ページを順番に、専門用語をできるだけ日常の例えに置き換えながら読み解きます。経営者の方に向けて、どの対策が何のためにあり、担当者や委託先に何を聞けばよいのかまで書きます。長い記事になりますが、資料の全ページを網羅します。

この記事の要点

• 政府が確認した原因は、新しい手口ではなく基本的な対策の不足です。アプリ開発時の対策不足、ウェブサイトの設定不備、サポートが終わったソフトや修正されていないソフトの使い続けが挙がっています。
• 文書の対策は3つの柱です。運用・管理（持ち物の把握と入口を減らすこと）、設計・開発（作る段階から安全にすること）、サプライチェーン（委託先や外部の部品を放置しないこと）です。
• 資料の最後は、経営トップの判断で、システムの特徴と保有する情報に基づくリスク評価を行うよう求めています。担当者に任せきりにしない、というのが経営者への一番のメッセージです。
• 文書が「やることのリスト」ではなく「考え方」を示している部分は、経営者が決める領域です。修正の期限、公開してよいものの基準、委託先に求める水準は、技術ではなく経営の判断です。
• 全部を一度にやる必要はありません。自社の入口を数える、不要な入口を閉じる、管理機能に多要素認証を入れる。この3つなら、今週から始められます。

先に押さえる言葉

資料を読み解くために、まず出発点になる言葉を表にします。ほかの略語は、出てきた場所でその都度説明します。

言葉	日常の例えで言うと
脆弱性（ぜいじゃくせい）	ドアの鍵の設計ミスのような、ソフトの弱点です。見つかると、ソフトの作り手が直した版（修正プログラム）を出します
アタックサーフェス	建物の出入口や窓の数です。使っていない裏口や窓が増えるほど、侵入される場所が増えます
OSS・ライブラリ	他人が作った部品を借りてソフトを組み立てる仕組みです。料理でいう既製のソースや調味料にあたります
API	アプリと裏側のサーバーをつなぐ、店の注文カウンターのようなものです。アプリが注文を出し、サーバーが応える窓口です
バックエンドサーバー	ウェブサイトやアプリの裏側にある厨房と倉庫です。ログインの確認や会員情報の保管をしています
サプライチェーン	自社だけでなく、システムの開発や保守を任せる委託先、使っている部品まで含めた、つながり全体です

政府は何を、誰に求めたのか

1ページ目に書かれていること

1ページ目は、文書全体の前置きです。ここに、政府の問題意識がすべて入っています。

政府は、昨今相次いでいる不正アクセスによる情報漏えいの事案で、次のような原因とみられる事例を複数確認していると述べます。モバイルアプリを作るときのセキュリティ対策が足りませんでした。ウェブサイトの設定に不備がありました。サポートが終わったソフトや、既に弱点が知られているのに手当てをしていないソフトを使い続けていました。しかも、これらは自社だけでなく、システムの開発や運用を任せた委託先でも起きていました¹。

どれも、聞けば当たり前のことです。新しい攻撃手法に破られたのではなく、基本ができていなかったのです。これが政府の見立てで、副題が「基本的な対策の徹底」である理由です。

攻撃者の動き方も書かれています。攻撃者は、インターネット上に公開されている日本のウェブサイトなどを標的に、大規模な調査をします。その調査で侵入の方法が見つかったサイトに入り込み、個人情報を盗んだとみられる、という説明です。たとえるなら、町じゅうの家のドアノブを片っ端から回して歩き、鍵のかかっていない家だけに入る泥棒です。

ここで文書は、標的の調査や侵害にAIを使っている可能性も高い、と述べます。そして、これまでの脆弱性診断では「比較的低い」と評価されたリスクでも、それらが組み合わさって侵入の原因になった可能性のある事例がある、と続けます。1つひとつは小さな穴でも、3つ重なると人が通れる、ということです。

もうひとつ、重要な一文があります。攻撃の大規模化が容易になったことで、事業規模の大小を問わず、幅広い事業者が攻撃対象になっていると考えられる、というものです。「うちは小さい会社だから狙われない」は、この文書では通用しません。

この文書の位置づけ

この文書が出る前の10月は、注意喚起が相次いだ月でした。個人情報保護委員会が10月7日、JPCERTコーディネーションセンターが10月8日、国家サイバー統括室と総務省がそれぞれ10月9日に、不正アクセスに関する注意喚起を出しています。さらに10月13日には、情報通信研究機構（NICT）の脅威情報分析チームが、詳しい攻撃手口を解説する注意喚起を出しました²。

今回の文書は、その流れの上にあり、ウェブサイトとモバイルアプリを運用して個人情報を扱う事業者に絞って、具体的な対策例まで示したものだと私は読んでいます。

文書そのものは、法律で義務を新設するものではなく、対策の徹底を「お願いいたします」と呼びかける形です。ただし、個人情報の取り扱いを委託する場合には、委託先に対して必要かつ適切な監督をすることが個人情報保護法第25条で求められていると、文書自身が後半で書いています¹。呼びかけの部分と、法律の義務の部分は、分けて理解する必要があります。

経営層向けと、担当者向け

1ページ目の最後に、読み方の案内があります。経営層をはじめ組織内の幅広い人に向けては、本文の「柱書（はしらがき）」として、対策の基本的な考え方と背景を整理した。ITシステム・サイバーセキュリティ担当者に向けては、枠で囲んだ具体的な対策例を載せた、という構成です。

つまり、各項目の冒頭の文章が経営者の読むところで、枠の中が担当者の作業リストです。この記事も同じ分担で書きます。経営者として押さえるべき考え方を先に、枠の中の対策例は、何のためにやるのかが分かる言葉に直して後に続けます。

13ページの地図

最初に、どのページがこの記事のどこに対応するかを示します。

ページ	内容	この記事の節
1	前置き（背景と読み方）	政府は何を、誰に求めたのか
2〜3	1の(1) デジタル資産の把握と脆弱性の解消	柱1の(1)
3〜4	1の(2) アタックサーフェスの棚卸しと最小化	柱1の(2)
4〜6	1の(3) AIの活用による継続的な診断と監視	柱1の(3)
6〜7	2の(1) セキュリティ・バイ・デザイン	柱2の(1)
7〜8	2の(2) 利用するAPIの対策	柱2の(2)
8〜9	2の(3) 公開前の脆弱性診断	柱2の(3)
9〜10	3の(1) 委託先の統制と接続経路	柱3の(1)
10〜11	3の(2) OSSや外部ライブラリの管理	柱3の(2)
11	締めの要請（経営トップの判断）	経営者は何を決め、何を聞けばよいのか
12〜13	参考資料と基準の一覧	参考

柱1　運用・管理の段階で、入口を減らし続ける

1つめの柱は、システムが動き始めたあとの話です。作って終わりではなく、動かしている間じゅう続ける対策が3つ並びます。

(1) 持ち物を把握して、弱点を塞ぐ（2〜3ページ）

不正アクセスの事案では、ウェブアプリの中で使われているライブラリやフレームワークに潜む弱点が悪用されている。文書はまずこう指摘します。特に、遠くからインターネット越しに悪用できる弱点は、会社の内部へ入り込む足がかりにされるおそれがある、とも書いています¹。

ここで経営者に知ってほしいのは、ソフトの弱点は「買った日」に決まらないという点です。導入した時には誰も気づいていなかった弱点が、運用を始めたあとに発見され、公表されることがあります。さらに、自社が直接買った製品だけでなく、その製品の中に組み込まれたオープンソースの部品にも弱点が出ます。

たとえば、市販のお菓子で、使われている原料の1つにリコールが出たとします。メーカーは、どの製品にその原料を使っているかをすぐ調べられなければ、回収が始められません。ソフトも同じで、「うちのシステムに、問題の部品は入っているのか」を即座に答えられる状態が必要です。文書が「継続的に把握するとともに、新たに公表される情報を集め、自組織への影響を速やかに特定・対処できる体制」を求めているのは、このためです。

そして、優先順位があります。インターネットから誰でもアクセスできるサーバーやネットワーク機器は、悪用のリスクが高いため、優先して対応するよう書かれています。

担当者向けの対策例は4つあります。順に、何のためのものかを説明します。

対策例1 ソフトの構成情報を把握・管理する。 使っているOS、ミドルウェア、フレームワーク、ライブラリについて、製品名、バージョン、どこで使っているかを記録します。この記録を自動で作る道具として、文書は「SBOM（ソフトウェア部品表）」と「SCA（ソフトウェア構成解析）」を挙げています。SBOMは、お菓子の原材料表示のソフト版です。何の部品がどのバージョンで入っているかの一覧で、経済産業省が導入の手引きを公表しています³。SCAは、その一覧を自動で作り、既知の弱点と照らし合わせる道具です。文書は、SBOMは作って終わりではなく、弱点情報との照合、影響範囲の特定、修正や暫定対策までを一連の運用として確保する必要があると、念を押しています。

対策例2 弱点の情報を継続的に集め、影響を確かめる。 どこから情報を集めるかも具体的に書かれています。米国のCISAが公開している「KEV」は、実際に悪用が確認された弱点の一覧です⁴。「弱点は何万件もあるが、いま現実に使われているのはこれ」と分かる名簿なので、まずここに載った弱点が自社のソフトに当たるかを優先して確認する、という使い方です。ほかに、各製品の作り手の発表、米国のNVD、日本のJVN（JPCERTコーディネーションセンターとIPAが共同運営する弱点のデータベース）も情報源として挙がっています⁵。人手では追い切れないので、必要に応じて、弱点の検知を自動化する管理ツールを使うとも書かれています。

対策例3 対応の優先順位と期限をあらかじめ決める。 弱点が公表されるたびに「どれから直すか」を議論していては間に合いません。弱点の深刻度、実際に悪用されているか、インターネット経由で悪用できるか、そのシステムの重要度と事業への影響。この4つを見る評価基準を、事前に決めておくよう求めています。

この対策例3は、私は経営者が自分で決めるべき部分だと考えています。たとえば「実際に悪用が確認されているものは何日以内に直す」という期限は、システムを止めてでも直すのかという事業判断と一体だからです。担当者が1人で決めると、止めたくない現場の事情に引きずられやすくなります。

対策例4 緩和策と、直したあとの確認。 修正プログラムをすぐに当てられない事情もあります。そのときは、製品の作り手が出す注意情報を見て、影響を受ける機能を止める、アクセスできる人を絞るといった暫定的な手当てをします。そして、当てたあとも、本当に効いているかを確かめ、残った弱点を管理し続けます。特に、すでに悪用が確認されている弱点については、関連するログ（記録）を確認して、既に侵入されていないかまで調べるよう書かれています。

最後の一文は、見落とされがちです。「直したから安心」ではなく、「直す前に入られていないか」を見る。弱点が公表されてから修正するまでの間に、攻撃者がもう入っていることがあるからです。

(2) 外から見える入口を数えて、減らす（3〜4ページ）

2つめの項目は、アタックサーフェス、つまり外から見える入口の話です。

文書は、不正アクセスによる情報漏えいの事案で、業務に不要な機能やサービスが外部に見える状態だったことが原因のものがあったと述べます。具体的には、インターネットに公開されたシステムの管理画面に対して、推測されやすいパスワードの悪用、総当たり攻撃、認証の弱点を突く迂回などで侵入された例があります。また、本来は外部に公開するつもりがなかった、デバッグ用の機能やシステム管理用の窓口が、インターネットから届く状態だったことも確認されています¹。

デバッグ用の機能というのは、開発中に不具合を調べるために作る、中身をのぞける裏口です。開発の間は便利ですが、公開するときに閉じ忘れると、そのまま外から入れる勝手口になります。

ここで文書が強調するのは、「要らない入口は、攻撃者に新しい侵入経路とデータを盗む機会を与える」ということです。裏口が1つ多いだけで、守る場所が1つ増えます。入口は少ないほど守りやすい。これは建物でもシステムでも変わりません。

担当者向けの対策例は3つです。

対策例1 入口の洗い出し。 ネットワークの構成情報、クラウドの設定、資産台帳から、インターネットに公開しているIPアドレス、ドメイン名、サービス、通信ポート、ウェブアプリ、APIを洗い出します。さらに「ASM（アタックサーフェス管理）」という道具で、会社の外側から観測できる資産を探し、社内の管理表と突き合わせます。ASMは、外から自分の会社を眺めて「こんな裏口があったのか」を数える作業と考えると分かりやすいと思います。経済産業省が導入ガイダンスを出しています⁶。突き合わせると、管理表から漏れていた資産や、意図せず公開されていたものが見つかります。見つかったものには、管理責任者、用途、公開の必要性を確認し、継続的に管理します。

対策例2 不要な公開機能を止める。 アプリケーションの側では、管理画面、デバッグ用の窓口、開発や検証用の環境、データベースの管理機能が、外から届くかどうかを点検します。特に、アクセスの振り分けの設定が、想定していない道筋に対してどう応えるかも確かめます。本来公開すべきでない機能に、外から届かないことを検証するのが目的です。不要な機能は止めるか無効にし、管理のために必要な機能は、アクセス元の制限と多要素認証を組み合わせて守ります。

多要素認証は、「パスワード」に加えて、スマートフォンの確認コードなど、もう1種類の証明を求める仕組みです。鍵に加えて暗証番号を求めるようなもので、パスワードが漏れても、すぐには入られません。

ネットワークとクラウドの側では、インターネットへの公開範囲やアクセス制限の設定を点検します。クラウドのストレージ（データ置き場）の公開設定、ファイアウォールが不要な通信を通していないか、ウェブサーバーが意図せずファイルを公開していないか、などです。設定の不備が見つかったら、公開の削除、権限の見直しなどで直し、直したあとは外からのアクセス確認で、本当に閉じたことを検証します。

対策例3 外から見える状態の継続的な監視。 システムを新しく作ったとき、変更したとき、設定を変えたときに、新しい入口や意図しない公開が生まれる可能性があります。そのため、点検は1回で終わらず、継続して行います。過去の点検結果や台帳と突き合わせ、把握していなかった資産や、公開状態の変化を検出して、見つけたら速やかに直します。

(3) AIも使って、点検と見張りを続ける（4〜6ページ）

3つめの項目は、作って公開したあとの「見張り」です。

文書は、構築時の対策だけでなく、運用を始めてからも診断や点検を続け、弱点や設定の不備を見つけ、ログの監視で不審な動きに気づき、侵入の兆候を早く見つけて対処することが重要とされてきた、と確認します。そのうえで、攻撃にAIが活用され、攻撃が高度化・効率化していくことを懸念しています。

ここが、この文書で最も新しい論点です。従来の対策を続けて強めるのに加えて、攻撃側がAIを使うのなら、防御側もAIの活用を積極的に検討すべきだと述べています。ただし、有効性、適用の範囲、運用上のリスクを十分に検証しながら導入する、という条件付きです。

もうひとつ、診断の頻度についての指摘があります。ウェブサイトやモバイルアプリの公開前だけでなく、認証・認可、API、個人情報の取り扱いなどに関わる重要な変更のとき、そして運用を始めたあとも、リスクに応じて継続的に診断・点検・監査を行い、見つかった弱点を直して結果を確認する。公開前に1回診断して終わり、という運用への警告です。

担当者向けの対策例は3つです。

対策例1 継続的な診断と点検。 ウェブアプリ、API、ネットワーク機器、クラウド環境に対して、定期的な脆弱性診断やペネトレーションテスト（本物の攻撃者のように侵入を試みる試験）を行い、重要な変更のときにも診断します。さらにAIを使った診断ツールの活用も検討します。攻撃経路の探索、テストの作成、弱点の確認、影響の分析、対応の優先順位づけの支援で、効率化できるとされます。ただし、AIの評価結果は根拠と妥当性を確認し、最終的な対応の判断は人が行う、と明記されています。

対策例2 ログと動作の継続的な監視。 ウェブサーバー、APIの入口、認証の基盤、クラウドサービスなどのログを取り、監視する体制を作ります。ここに略語が3つ出ます。SOC（セキュリティ・オペレーション・センター）は、警備室にあたる監視の拠点や体制です。SIEM（シーム）は、各所のログを集めて相互に突き合わせる仕組みで、防犯カメラの映像をまとめて見る警備モニターのようなものです。EDR（イーディーアール）は、パソコンやサーバーの中での怪しい動作を見張るソフトです。これらで、不審な認証、権限の不正な使用、大量のデータ取得を継続的に監視します。AIで、大量のログやアラートを横断的に分析し、異常の兆候の検出や、複数の事象の関連づけ、調べる順番づけを行う活用も、積極的に検討するよう書かれています。

対策例3 調査と初動対応の迅速化。 怪しい動きや侵入の兆候を見つけたら、関連するログやシステムの状態を素早く調べ、不正アクセスの有無と影響範囲を確かめられる体制を整えます。SOAR（ソアー）は、調査や対応の手順を自動化する仕組みで、警備員の初動マニュアルをシステムに覚えさせるようなものです。AIによるアラートの要約、関連情報の収集・分析、対応手順の提案も検討対象です。こちらも、誤検知や誤判断が事業に与える影響を考え、適切な検証と人による監督のもとで行う、と書かれています。

3つに共通するのは、AIは担当者を助けるが、最後の判断を任せるものではない、という姿勢です。私もこれは妥当だと思います。AIに任せきりにして止めてはいけないシステムを止める誤判断が起きれば、経営の損失になるからです。

柱2　設計・開発の段階で、最初から安全に作る

2つめの柱は、システムを作る段階の話です。文書は、昨今のサイバー攻撃の傾向を踏まえると、モバイルアプリやウェブのクライアント、その裏のサーバーが、必ずしも安全に作る考え方で設計されていないことが多い、と指摘します。

(1) セキュリティ・バイ・デザイン（6〜7ページ）

「セキュリティ・バイ・デザイン」は、後から守るのではなく、最初から安全に作るという考え方です。建物でたとえると、完成してから非常口や防火壁を足すのではなく、設計図の段階から組み込んでおくことにあたります。

文書は、万が一、弱点や設定の不備がリリース後に見つかった場合、後から直す費用は、設計の段階で防ぐ場合に比べて大幅に増えると書いています。加えて、重大な事故や情報漏えいにつながるおそれがあるとも指摘します。そのため、要件を決める段階から運用までの全工程にセキュリティを組み込むよう求めています⁷。

担当者向けの対策例は3つあります。

対策例1 要件定義・設計の段階で、安全な作りを考える。 「脅威モデリング」という作業が挙がっています。このシステムは誰にどう攻撃されうるか、どの入口が狙われるかを、設計の段階で洗い出す作業です。そのうえで、認証・認可、暗号化、ログの記録、アクセスの制御といった、安全に関する要件を決めます。管理や運用の機能を、うっかりインターネットに出さないネットワークの構成にすること、そして「ゼロトラスト」の考え方にもとづくアクセスの制御も、設計から考えるよう書かれています。ゼロトラストは、社内にいるから信用する、をやめて、誰が何にアクセスするときも毎回確認する考え方です。

さらに、アプリケーション、データベース、運用管理機能を、ネットワーク上で分けるだけでなく、システムの重要度とリスクに応じて、クラウドのアカウントなどの管理の境界ごと分けることも検討するとあります。1つが破られても、全部には及ばないようにする、という発想です。

設計の基準には「非機能要件」も入れます。これは、画面や機能の仕様に出てこない、認証、可用性（止まらないこと）、ログ、監視、障害時の対応、バックアップ、データの保護といった要件のことです。作る側と発注する側の間で、ここの認識がずれていると、「機能は動くが守りが空っぽ」になりやすいので、要件を決める段階から調達、開発、検収、運用の各段階で確認する項目を明確にするよう求めています。

対策例2 作る段階の自動点検（SAST、SCA）。 SASTは、プログラムのソースコードを動かさずに読んで、危ない書き方を見つける自動点検です。文書は、危険な関数の使用やセキュアコーディング違反、使っているOSSやライブラリに含まれる既知の弱点を、継続的に把握できると述べています。SCAは前に出てきた、部品の弱点を調べる道具です。必要に応じて、SBOMも使います。これらは、料理でたとえると、調理の途中で「この材料は傷んでいないか」を確かめる検品にあたります。

対策例3 試験の段階の自動点検（DAST、IAST）。 DASTは、実際に動いているアプリケーションに対して、外から攻撃者のようにリクエストを送って弱点を探す点検です。IASTは、アプリケーションの動作中に、内側から対話しながら点検する方式です。認可の不備、入力値の確認不足、ログイン状態の管理の不備などを、自動の分析で見つけ、必要に応じて手作業でも確かめ、リリース前に直します。必要なら、こうした点検を「CI/CD」というソフトを作って公開する流れの自動化の仕組みに組み込み、開発の全期間を通して継続的に安全を確かめます。

(2) 利用するAPIの守りを固める（7〜8ページ）

ここは、この文書の中心とも言える部分です。文書は、不正アクセスによる情報漏えいの事案で、ウェブアプリやモバイルアプリが使うAPI経由の不正な操作が原因のものが確認されていると述べ、NICTが注意を呼びかけた「A2B攻撃」を例に挙げています¹。

A2Bは「App-to-Backend」、つまりアプリから裏側のサーバーへの攻撃です。NICTの脅威情報分析チームの注意喚起によれば、攻撃者はまず、公開されているアプリを入手して解析し、アプリが通信する裏側のサーバーの接続先、APIの構成、通信に使うパラメータなどを調べます。そのうえで、集めた情報をもとに、個々のサーバーの構成やAPIの仕様に合わせた攻撃を組み立てて、弱点を狙っています。確認されたのは、Google Playの日本地域で公開されているAndroidアプリを入手して解析する手口でした²。

飲食店でたとえましょう。お客さんが使うのは、メニュー表（アプリ）です。ところが泥棒は、メニュー表をじっくり読み込み、「この店は、厨房へ注文を通すカウンター（API）の場所がここで、注文の書き方はこう」と調べ上げます。そして、メニュー表を使わずに、カウンターへ直接、細工した注文を出して、厨房や倉庫の中身（個人情報）を引き出そうとします。

NICTの注意喚起で重要なのは、次の指摘です。この攻撃では、アプリ自体に弱点がなくても、裏側のAPIに認証・認可や入力値の検証などの不備があれば、個人情報の漏えいや不正アクセスにつながりうる。そして、公開されたアプリが解析されること自体を完全に防ぐのは難しい。大切なのは、アプリの中身やAPIの仕様が攻撃者に知られても、裏側のサーバーの安全が保たれるように作り、運用することだ、と述べています²。

NICTは、主に狙われている弱点として4種類を挙げています。SSRF（サーバーに、本来意図していない通信をさせる弱点）、RCE（外から送った命令を、サーバー上で実行されてしまう弱点）、SQLインジェクション（入力を通じて、データベースに不正な命令を実行させる弱点）、IDOR（利用者の識別番号を書き換えるだけで他人の情報が見えてしまう弱点）です。IDORは、たとえるなら、ホテルのルームキーが、番号を1つ変えるだけで隣の部屋も開けてしまう状態です。この4つは、次の「公開前の診断」でも出てきます。

なお、この種の事案を、私たちはすでに見ています。2026年10月15日、ソースネクストは、会員情報を取得するAPIへの不正アクセスで、最大2,251万9,960件の情報が流出した可能性を公表しました。当社の記事では、公表された事実とまだ分かっていないことを分けて、APIの守り方を整理しています。この事案の原因が、今回のNICTの注意喚起と同じ手口だったかどうかは、現時点で確認できていません。ソースネクストの事案から学ぶ、会員情報APIの守り方も合わせて読んでください。

文書は、APIの守りとして、堅牢な認証と認可の実装、厳格な入力値の検証、認証情報の安全な管理、異常なアクセスの検知と制御を実施することが重要と述べます。担当者向けの対策例は3つです。

対策例1 認可不備をなくす。 認可というのは、「その人にその操作をしてよいか」の確認です。認証（本人確認）とは別物で、ここが最も見落とされます。ログインした本人であっても、他人の情報までは見られないようにしなければなりません。文書は、APIの要求が求めている機能とデータに対して、利用者が正当な権限を持っているかを、サーバー側で確認し、「最小権限の原則」に基づいたアクセス制御を実装するよう求めています。最小権限の原則は、仕事に必要な最小限の権限だけを渡す、という考え方です。認可の不備には、「BOLA（オブジェクト単位の認可不備）」と「BFLA（機能単位の認可不備）」の2種類があります。BOLAは前に述べたIDORと同じ種類のもので、他人のデータに触れてしまう不備です。BFLAは、一般の利用者が、管理者向けの機能を使えてしまう不備です。どちらも、OWASPという世界的な非営利団体が、APIの重大な弱点として整理しています⁸。

対策例2 認証情報を安全に管理する。 APIキー、アクセストークン、秘密鍵、データベースの接続情報は、いわば合鍵です。これをソースコードやアプリの中に直接書き込んでいると、ソースコードが漏れたときや、アプリを解析されたときに、盗まれます。看板に暗証番号を書いて貼っておくようなものです。文書は、合鍵をソースコードに書き込まず、サーバー側では「シークレットマネージャー」という鍵の保管庫の仕組みで管理するよう求めています。合鍵には必要最小限の権限だけを与え、有効期間を決め、定期的に取り替えます。開発の工程でも、ソースコード管理の場所にコミットするとき、CI/CDの流れの中で、うっかり合鍵が混ざっていないかを機械的に検査（シークレットスキャン）する仕組みを整えます。

対策例3 APIの回数制限で、不正利用を防ぐ。 APIは、自動化されたツールで、パスワードを片っ端から試す総当たり攻撃や、情報の収集の標的にされます。そこで、短い時間に大量のリクエストが送られたときは、受け付けを制限します。窓口の整理券で「1分間に受け付けるのは何人まで」と決めるのに似ています。特に、ログインやパスワードの再設定は、狙われやすい機能です。同じIPアドレスや同じアカウントからだけでなく、複数のIPアドレスからの分散したアクセスも含めて、成功・失敗の状況やアクセス頻度から、異常を検知する仕組みを設けるよう書かれています⁹。

(3) 公開する前に、弱点を診断する（8〜9ページ）

3つめは、開店前の内覧会のような話です。文書は、SQLインジェクション、OSコマンドインジェクション、リモートコード実行（RCE）、サーバーサイドリクエストフォージェリ（SSRF）、ディレクトリトラバーサルといった弱点を悪用した攻撃で、情報漏えいが起きていると述べます。名前は難しいですが、いずれも「外から送る入力や要求に細工をして、サーバーに想定外のことをさせる」類の弱点です。

そのため、個人情報を扱うウェブアプリやウェブシステムは、リリース前に脆弱性診断やペネトレーションテストを行い、潜在的な弱点を事前に見つけて直すことが重要です。診断の目的や対象範囲を明確にし、見つかった弱点を適切に直して、結果を確認したうえで本番環境へ公開する、と書かれています。

2つ、見逃せない指摘があります。1つめは、診断の対象です。製品やプラットフォームに既に知られている弱点だけでなく、自社や委託先が開発した、ウェブアプリやモバイルアプリの裏側の機能に固有の、設計や実装上の弱点も、診断と是正の対象にしなければならない、という点です。市販のソフトの検査だけでは、自社固有の作り込みの弱点は見つかりません。2つめは、ウェブアプリの技術的な検証項目は、対象システムの特性とリスクに応じて範囲を決めることが重要だ、という点です。全項目を一律にやるのではなく、自社のシステムに合わせて決めます。範囲を決める国際的な基準として、OWASPのASVSが参考資料に挙がっています¹⁰。

担当者向けの対策例は2つです。

対策例1 セキュリティの基準を決める。 診断をするときは、あらかじめ「どこまでのリスクなら受け入れるか」の水準を決め、それをもとに、リリースしてよいかを判断する運用を整えます。たとえば、弱点の深刻度、悪用のされやすさ、システムの重要度を見て、基準を設け、一定以上のリスクが残る状態では、本番公開をしないという方針を決めます。診断結果に対する、修正の責任者と期限を明確にし、直し漏れを防ぐ仕組みも作ります。

これも経営者に関わる部分です。「リリース日が迫っているが、弱点が残っている」というとき、誰が公開か延期かを決めるのか。その基準がなければ、毎回、現場が納期とセキュリティの板挟みになります。この基準を決めるのは、技術ではなく経営の仕事だと私は考えています。

対策例2 第三者の診断業者を適切に選ぶ。 診断を外部に委託する場合は、対象のシステムの特性や使っている技術を踏まえ、十分な技術力と実績を持つ事業者を選びます。特にウェブアプリ、API、モバイルアプリの診断の実績や手法、体制を確認します。また、「情報セキュリティサービス基準」に適合したサービスを提供している事業者を選ぶよう挙げています。この基準に合うと認められた事業者は、審査登録制度の「情報セキュリティサービス台帳」に載ります。さらに、自動診断だけでなく、手作業による検証や、業務の流れ（ビジネスロジック）を考えた診断が行われるかも確認する、という指摘は重要です。たとえば「ポイントを不正に増やせる」といった、その会社の業務に固有の穴は、自動の検査では見つけにくいからです。

柱3　サプライチェーンを通じた侵害に備える

3つめの柱は、自社の外の話です。ウェブサイトやアプリの開発、保守を外部に任せている会社には、特に重要な部分です。

(1) 委託先の統制と、接続経路を固める（9〜10ページ）

文書は、業務の委託先や保守事業者の環境を足がかりに、発注元のシステムへ侵入される事案が確認されていると述べます。特に、委託先が使うリモート接続の環境は、攻撃者にとって「正規の認証情報を使った侵入口」になりうる、という指摘です。

ここで文書は、重い一文を置いています。こうした場合でも、サービスの停止や情報漏えいによる影響は、発注元である事業者自身が負うことになる、というものです。委託先が不正アクセスの入り口になったとしても、お客様から見れば、被害を出したのは発注元の会社です。委託先に責任を移して済む話ではありません。

法律の面でも、個人情報の取り扱いを委託する場合は、個人情報保護法第25条により、委託先に対する必要かつ適切な監督が求められています¹¹。文書は、委託先を含むサプライチェーン全体を管理・統制の対象とし、委託先に対する統制（ガバナンス）と、接続経路の多層的な防御の両輪で対策を考えるよう求めています。

同時に、文書は発注側にも注意を向けています。委託先に対策を求めるときは、費用の負担や実施方法について十分に協議し、取引上の立場の強さを利用した、一方的な負担の押し付けにならないよう留意するように、と書かれています¹²。「やれ」と言うだけでは、委託先は費用を捻出できず、対策が形だけになります。費用を誰が持つのかまで話し合うことが、実効性のある対策の条件だということです。

担当者向けの対策例は3つです。

対策例1 委託先からの接続経路とアカウントを守る。 委託先が使うVPN、リモートデスクトップ、保守用の回線などの接続経路を洗い出し、多要素認証を適用します。文書は、重要度の高い経路から計画的に切り替える、多要素認証が難しい経路には、接続元のIPアドレスの制限、作業するときだけ接続を開ける運用、作業記録の取得などの代わりの手を打つ、と現実的に書いています。そして、作業が終わった委託先のアカウントや、常時付与されたままの管理者権限を棚卸しして、無効化や最小化をします。

対策例2 契約や調達で、セキュリティの要件を明確にする。 発注の仕様書や業務委託の契約書に、秘密保持の義務に加えて、再委託の手続き、インシデント発生時の通知義務と連絡先、契約が終わったときのデータ消去などの要件を入れます。委託先を選ぶときは、第三者認証や、経済産業省の「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」などの客観的な評価を活用します。

SCS評価制度は、取引先のセキュリティ対策の水準を、統一された「★（星）」で示す制度です。IPAによると、★3は自己評価をもとに専門家が確認する方式で有効期間は1年、★4は評価機関による実地の審査と技術検証がある第三者評価で、有効期間は3年とされています。★5は検討中です。登録申請の受付は2027年3月に始まる予定です。星の取得は任意で、取引の条件にするかどうかは、当事者が決めます¹³。まだ始まっていない制度なので、今すぐ使えるものではありませんが、取引先を選ぶときの共通のものさしになる可能性があります。

対策例3 ゼロトラストの考え方でアクセスを制御する。 「一度つながれば、社内ネットワークの広い範囲に入れてしまう」境界型のVPNだけに頼る状態から脱します。委託先の作業員ごとに、認められた端末から、必要なサーバーや機能にだけ通信できるよう限定します。社員証で建物に入れても、各部屋に入るには別の許可が要る、というイメージです。IPAがゼロトラストの導入指南書を公開しています¹⁴。

(2) オープンソースや外部ライブラリを、中身が分からないまま使わない（10〜11ページ）

システムの開発で、OSSや外部ライブラリを使うことは避けられません。一方で、深刻な弱点が公表されると、攻撃者が短期間のうちに探して悪用する場合がある、と文書は述べます。そのため、外部の部品を、中身が分からないまま使い続けることを避ける必要があります。部品を可視化し、素早く対処できる体制を整えてほしいというのが、この項目の要請です。

担当者向けの対策例は2つあります。

対策例1 深刻な弱点が公表されたときの初動手順を決めておく。 文書が想定しているのは、修正がまだ提供されていない弱点（ゼロデイ脆弱性）への注意喚起や、深刻な弱点の公表で、緊急の対応が求められる場面です。そこで保守事業者に任せきりにせず、素早く判断できる手順を、あらかじめ決めておくよう求めています。

具体的には、開発や保守を委託している自社の主要なシステムで、組み込まれているOSSのバージョンやサポート終了（EOL）の状況を、平時から把握します。公開情報をもとに、委託先と連携して、自社のシステムへの影響の有無を素早く照合します。影響を調べる責任者、委託先との役割分担、経営層への報告の基準を決めます。そして、修正プログラムの適用、あるいはWAF（ウェブアプリケーション・ファイアウォール、ウェブサイトへの不正な通信をはじく防護壁）などによる防御や、該当の機能の停止といった、暫定対策を判断する手順も決めておきます。

この「経営層への報告の基準」は、経営者がぜひ自分で見直してほしい項目です。弱点が公表された日に、何をもって社長に報告が上がってくるのか。基準が曖昧だと、「大したことはない」と現場が判断した情報が、止まったままになります。

対策例2 委託開発でSBOMを提出させ、確認する。 開発や改修を委託するときに、使うソフトの部品の明示とSBOMの提出を、契約や仕様に定めます。検収のときは、提出されたSBOMと設計書を突き合わせ、既知の弱点やライセンス違反がないかを確認します。納品後も、SCAの道具などで、新しく公表される弱点を継続的に監視する体制を整えます。納品して終わりではなく、納品後に出てくる弱点まで見張る、という点が重要です。

11ページの結びと、12〜13ページの参考資料

11ページの最後に、文書全体のまとめにあたる文章があります。ここまでの対策は、昨今の一連の攻撃手口に焦点を当てたものだと断ったうえで、VPNなどインターネット上にさらされたネットワーク機器の弱点を狙う攻撃、標的型のメール攻撃、DDoS攻撃（大量のアクセスでサービスを止める攻撃）などの手口、さらにAIの悪用が高度化・巧妙化する可能性まで想定して、対策を講じる必要があると述べます。

そして最後に、こう結びます。サイバー攻撃による影響が、経営のリスクへと発展する可能性も考え、経営トップの判断のもとで、運用しているシステムの特徴や保有している情報の内容に基づくリスク評価を行ったうえで、必要なサイバーセキュリティ対策の強化をお願いしたい、というものです¹。

この結びが、文書全体の要です。担当者向けの対策例が何十個も並んでいても、全部をやれと言っているのではありません。自社のシステムと保有情報に応じてリスクを評価し、優先順位をつけるのは、経営トップの仕事だというのです。

12〜13ページは、参考資料の一覧です。経済産業省のSBOM導入手引き、ASM導入ガイダンス、IPAの「安全なウェブサイトの運営管理に向けての20ヶ条」や「ECサイト構築・運用セキュリティガイドライン」、「セキュリティ・バイ・デザイン導入指南書」、デジタル庁のガイドライン、NICTの注意喚起、OWASPのAPIセキュリティの10大リスク、個人情報保護委員会のガイドライン、IPAの中小企業向けガイドラインの規程サンプルなどが挙がっています。巻末には、政府機関等と重要インフラ向けの、サイバーセキュリティ対策の統一基準が「基本的な対策についての基準」として添えられています。経営者が全部読む必要はありませんが、担当者や委託先に「この資料を踏まえているか」と聞くときの、共通の言葉になります。特に、中小企業の方が最初に開くなら、IPAの「安全なウェブサイトの運営管理に向けての20ヶ条」が入口として使いやすいでしょう¹⁵。

経営者は何を決め、何を聞けばよいのか

ここからは、文書の内容を踏まえた、私なりの整理です。政府の文書そのものではないことをお断りしておきます。

経営者が自分で決める3つのこと

担当者に任せてはいけないのは、技術の細部ではなく、次の3つの判断です。

1つめは、修正の期限です。実際に悪用が確認されている弱点は何日以内に直すのか。止められない時間帯のシステムはどうするのか。担当者が1人で決めると、現場の都合に流されます。

2つめは、公開してよいかの基準です。診断で弱点が見つかったとき、どの水準なら公開を延期するのか。リリース日と安全のどちらを優先するのかを、事前に決めておきます。

3つめは、報告の基準です。深刻な弱点が公表されたとき、何が起きたら経営層に報告が上がるのか。報告が上がってから何時間で、判断する場を設けるのか。

担当者・委託先に聞く10の質問

次の質問を、担当者と委託先に投げてみてください。答えが詰まるところが、自社の弱いところです。

質問	対応する文書の項目
インターネットに公開しているサービスと管理画面の一覧はありますか	柱1の(2)
使っていない機能、開発環境、検証環境が外から届く状態になっていませんか	柱1の(2)
弱点が公表されたとき、自社のシステムに影響があるか、何時間で答えられますか	柱1の(1)
サポートが終わったソフトを使い続けていませんか	柱1の(1)
管理画面とクラウドの管理機能に、多要素認証を入れていますか	柱1の(2)・柱3の(1)
ログを取っていて、不審な動きに誰が気づく体制ですか	柱1の(3)
アプリの裏側のAPIで、他人のデータに触れないことを確かめましたか	柱2の(2)
公開前の診断で、自社固有の作り込みの部分も見ていますか	柱2の(3)
委託先の接続経路に、多要素認証はありますか。作業が終わったアカウントは消していますか	柱3の(1)
委託開発で、使っている部品の一覧（SBOM）を納品させていますか	柱3の(2)

規模が小さい会社は、どこから始めるか

文書は、リスクに基づいて優先順位をつけるよう求めています。そのうえで、人も予算も限られる中小企業の方に、私が勧める順番を書きます。これは文書が示す順番ではなく、私の考えです。

最初にやるのは、入口を数えることです。自社が外に出しているサイト、アプリ、管理画面、クラウドの置き場を、書き出します。費用はかからず、委託先に聞けば分かることも多くあります。数えて初めて、「こんなものを公開していたのか」が見つかります。

次に、要らない入口を閉じます。使っていない管理画面、古い検証環境、昔のキャンペーン用のページは、見つけたその日に止めて構いません。止めて困るかもしれないと感じたら、まず外から見えなくするだけでも効果があります。

3つめが、管理機能に多要素認証を入れることです。管理画面、クラウドの管理者アカウント、委託先のリモート接続が優先です。ここが破られると、被害が一気に広がります。

そのあと、修正の期限を決め、委託先に接続経路とAPIの認可について、書面で答えてもらいます。診断や監視といった費用のかかる対策は、この棚卸しの結果を見て、どこに当てるかを決めると、無駄がありません。

自社の現在地が分からないときは、AIリテラシー診断のように、社内の理解度を測る入口から始める方法もあります。また、実際に事故が起きたときの動き方はサイバーインシデントの初動をまとめた記事に、パソコンや端末側の備えは中小企業向けのチェックリストに書いています。また、弱点が公表されたときに備える運用は、PHPの重大脆弱性の記事で具体的に整理しました。

おわりに

この文書を読んで一番強く感じたのは、書かれている内容の新しさではなく、「当たり前のことを、当たり前にやり続ける難しさ」でした。持ち物を数える。要らない入口を閉じる。直すべきものを直す。委託先任せにしない。どれも、聞けば誰でも頷く対策です。

それでも事故が続くのは、これらが「一度やれば終わり」ではなく、システムが変わるたびに、人が入れ替わるたびに、やり直しが必要な仕事だからだと思います。新しい機能を足せば入口が増え、部品が更新されれば弱点が増え、委託先が変われば接続経路が変わる。担当者が忙しくなるほど、後回しにされる仕事でもあります。

だからこそ、経営者の関与が要る、というのが文書の最後の一文の意味でしょう。修正の期限や、公開の基準や、報告のルールは、担当者が1人で決めようとすると、現場の忙しさに押されてしまいます。決めるのは経営者、動くのは現場。この分担を、今週のうちに確認してみてください。

そして、まだ時間があるなら、自社の入口を数える作業を、担当者と一緒に1時間だけやってみてください。意外なものが見つかるはずです。

社内の運用ルールの整え方や、委託先とのやり取りの進め方に迷う場合は、当社のWARP SECURITYも選択肢になります。攻撃手口の解説より、社内の承認や発覚時の判断といった、平時の備えに時間を割く研修です。ご相談は個別相談からどうぞ。

参考

Footnotes

1. 内閣官房国家サイバー統括室「個人情報の漏えい等につながる不正アクセスへの対策について ～ウェブサイトやモバイルアプリに関する基本的な対策の徹底～」2026年11月5日（事業者向け、全13ページ）。本記事の事実の記述は、特に断りがない限りこの文書によります。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

2. 国立研究開発法人情報通信研究機構（NICT）脅威情報分析チームLETTICE「【注意喚起】相次ぐ情報漏洩、その原因の一つは『アプリ解析からのサーバ攻撃』」2026年10月13日。参考文献欄に、個人情報保護委員会（10月7日）、JPCERT/CC（10月8日）、国家サイバー統括室（10月9日）、総務省（10月9日）の注意喚起が挙がっています。PDF ↩ ↩² ↩³

3. 経済産業省「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 ver2.0」2024年8月。経済産業省 ↩

4. 米国CISA「Known Exploited Vulnerabilities Catalog（既知の悪用された脆弱性カタログ）」。CISA ↩

5. JPCERTコーディネーションセンターとIPAが共同運営する脆弱性対策情報データベース「JVN」。JVN ↩

6. 経済産業省「ASM（Attack Surface Management）導入ガイダンス ～外部から把握出来る情報を用いて自組織のIT資産を発見し管理する～」2023年5月。経済産業省 ↩

7. IPA「セキュリティ・バイ・デザイン 導入指南書」。IPA ↩

8. OWASP「API Security Top 10 2023 API1 Broken Object Level Authorization」。OWASP ↩

9. OWASP「API Security Top 10 2023 API4 Unrestricted Resource Consumption」。OWASP ↩

10. OWASP「Application Security Verification Standard（ASVS）」。OWASP ↩

11. 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」（委託先の監督）。個人情報保護委員会 ↩

12. 経済産業省・公正取引委員会「サプライチェーン全体のサイバーセキュリティ向上のための取引先とのパートナーシップの構築に向けて」。経済産業省 ↩

13. IPA「SCS評価制度 よくある質問」。★3・★4の方式と有効期間、登録申請の受付開始時期（2027年3月予定）、★5は検討中であることは、同ページの記載によります。IPA ↩

14. IPA「ゼロトラスト導入指南書～情報系・制御系システムへのゼロトラスト導入～」。IPA ↩

15. IPA「安全なウェブサイトの運営管理に向けての20ヶ条」。IPA ↩