0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@Regryp

AIで攻撃される前提の開発と運用 ~昨今のサイバー攻撃を踏まえた対応〜

0
Posted at

2026年10月24日時点の公開情報をもとに書いています。推測が含まれる部分もあります。

はじめに

2026年10月、AIを使ったペネトレーションテストツールが実際の攻撃に使われているという報告が、CrowdStrike、Microsoft、国内のセキュリティ企業から相次ぎました。同じころ国内では、9月下旬からの1か月ほどで数十の組織が不正アクセスによる情報漏えいを公表し、JPCERT/CCをはじめ各機関が注意喚起を出しています。

この記事では、直近3か月（2026年7月下旬〜10月）のインシデントを整理したうえで、攻撃側で何が変わったか、防御側は開発から運用までのどこで何をすべきかをまとめます。後半では、AWSでの組み方と、技術以外の組織の判断・訓練についても扱います。

なお、ここで取り上げる事案は、公表資料や報道をもとにしたものです。

1. 最近の主要インシデント

1.1 アルカディア（SpeeCAN RAIDEN）

自治体などが使う防災情報の一斉配信サービス「SpeeCAN RAIDEN」を提供するアルカディアが、2026年10月11日に不正アクセスを受けました。同社は10月19日と23日に、経過をまとめた報告書を公表しています。

報告書によると、侵入の起点は、添付ファイルを公開するメディアサーバーのディレクトリパストラバーサルの脆弱性でした。そこから設定ファイルが読み取られ、中にあったサービス間のログイン用シークレットキーが流出。そのキーを使ってアカウントへのログインが成立し、内部情報が取得されました。その後、CMS（WordPress）に不正なプラグインが仕込まれ、そこを経由して大量の不正メールが外部に送信されています。

項目 内容
公表日 2026年10月19日・23日（経過報告）
侵入の起点 公開サーバーのディレクトリパストラバーサル → 設定ファイル内のシークレットキー流出
漏えいの可能性（最大・推定） メールアドレス約313.6万件、電話番号約10.5万件、FAX番号約1.5万件。NET119分は9,020件で確定
二次被害 不正メール約142万通を外部配信（カード会社を装うフィッシングの疑い）
検知まで 攻撃開始（10/11 6:26）から検知（同日23:40）まで約17時間。きっかけはDBの異常な負荷
サービス影響 一部サービスを約52時間緊急停止。復旧対応中の設定変更で、外部連携・電話発信・自動応答にも一時不具合

この事案から読み取れることは3つあります。

  • 原因は、製品のCVEではなく自社のコードと設定にあった。 ディレクトリパストラバーサルという古典的な脆弱性と、設定ファイルに置かれた秘密情報です。脆弱性スキャナーで製品の既知CVEを追うだけでは見つかりません。
  • 攻撃開始から17時間、検知できなかった。 その間に探索が進んでいました。既知の攻撃パターンだけでなく、振る舞いの異常を見る必要があります。
  • 復旧対応そのものが障害を生んだ。 侵入経路を塞いだ後にDBのパスワードを変えたところ、どのサービスがその認証情報に依存しているか把握しきれておらず、外部連携などが止まりました。

なお、報告書には攻撃にAIツールが使われたという記述はありません。ただ、公開サーバーの脆弱性から設定ファイル・認証情報へと順にたどる流れは、後述するAIペネトレーションツールが自動化している動きとよく似ています。同社は再発防止策として、全サービスで社内LLMを使った脆弱性診断とコードレビューを実施したと述べており、10月23日の記者会見では、AIを活用した防御の導入を検討するとしています。

1.2 国内で相次いだ不正アクセス

2026年9月下旬からの約1か月で、国内では多数の組織が不正アクセスによる情報漏えいを公表しました。主なものを挙げます（件数は各社の公表時点の値で、「漏えいの可能性」を含みます）。

公表日 組織 件数 対象・経路（公表範囲）
9/28 タイムズカー（パーク24） 約660万アカウント（本人確認書類画像 約160万） Webシステムへの不正アクセス
10/5 焼肉きんぐ（物語コーポレーション） 10,788,963件 公式アプリの会員管理システム
10/5 大和証券 約11万人 委託先（スカラコミュニケーションズ）への不正アクセス
10/8 ローソン 2,155,345件 公式アプリ関連システムへの不正アクセス
10/8 第一興商 約872万件 委託先の従業員端末のマルウェア感染
10/9 ブックオフグループ 最大約643万件 会員管理システム
10/7〜 IDCフロンティア（IDCFクラウド） 495の企業・自治体に影響 ランサムウェア。JR東日本などに波及
10/15 ソースネクスト 22,519,960件 会員情報取得APIの悪用
10/15 バーガーキング（ビーケー・ジャパン） 約1,118万件 公式アプリの会員管理システム
10/16 ショップサーブ（Eストアー） 約2,335万人 サーバー上のアプリの脆弱性
10/19 ユミルリンク（Cuenote FC） 延べ約900万件 脆弱性から認証情報を取得し不正プログラムを設置

件数と原因は、各社の公表資料と報道をもとにしています。ここから読み取れる傾向は2つです。

  • 公式アプリの会員管理システムが多い。 スマートフォンアプリの裏にあるAPIやデータベースが狙われています。
  • 委託先や共通基盤を経由した波及が目立つ。 問い合わせシステムの提供元（スカラコミュニケーションズ）、クラウド基盤（IDCフロンティア）、メール配信基盤（ユミルリンク）への攻撃が、それを使う複数の企業に広がりました。

この流れを受けて、各機関が注意喚起を出しています。

  • JPCERT/CC（2026年10月8日公表、23日更新）は、攻撃の手口を5つの類型に整理しました。既知脆弱性の探索、公開アプリを解析してAPIを突く手口、Metabaseの脆弱性（CVE-2026-72898）、Webシェルの設置、そして「AIペネトレーションテスト基盤の悪用」です。最後の類型には、後述するCairn、CyberStrikeAI、ARTEXの名前が挙がっています。
  • NICT（2026年10月13日）は、公開されているAndroidアプリを解析してAPIの構造を把握し、その裏側のサーバーを攻撃する手口を「A2B攻撃（App-to-Backend Attack）」と名づけて注意喚起しました。アプリ自体に欠陥がなくても、サーバー側の認可の不備（IDOR/BOLA）やSSRF、RCE、SQLインジェクションがあれば被害につながると指摘しています。
  • このほか、個人情報保護委員会、警察庁、国家サイバー統括室、総務省、経済産業省、IPA、金融庁が、10月上旬に相次いで注意喚起を出しました。IPAは10月16日に不正アクセスの特別相談窓口を開設しています。

また、GMOサイバーセキュリティ byイエラエは10月19日、日本企業を狙った攻撃元インフラの1つでARTEXの使用を確認したと発表しました。このインフラの標的は日本企業約20社で、別にAIを使う攻撃インフラも6台見つかったとしています（標的の数は、侵害に成功した数とは異なります）。

1.3 デジタル庁（GSS）

政府共通の業務基盤「ガバメントソリューションサービス（GSS）」が不正アクセスを受け、デジタル庁は2026年9月11日、約24.6万件の個人情報が漏えいした可能性があると公表しました。入口は保守運用に使われていたVPN機器の脆弱性で、侵入後、保守運用担当者のアカウントでサーバー上の大量のファイルにアクセスされています。

この事案は、悪用された脆弱性の深刻度が公表時には「中（Medium）」だった点が重要なので、パッチの優先度の話として4.8で詳しく取り上げます。

1.4 海外の事案

直近3か月は、海外でもAIペネトレーションツールを使った攻撃が報告されました。

  • 韓国の金融機関：CrowdStrikeが2026年10月7日に報告。9月下旬から10月上旬にかけて、ARTEXを使って複数の金融機関が攻撃され、約68,000人分の個人情報が漏えいした可能性があるとされます。入口は、認証の弱い公開システムでした。
  • ConnectWise（サプライチェーン攻撃）：Microsoftが10月21日に公表。中国国家系とされるStorm-0940がARTEXを使い、9月上旬から世界の数百組織を標的にしました。クラウドアプリの信頼関係を悪用し、2,250を超えるテナントにサインインを試みています。標的にしてから重要な権限を得るまで3時間かからなかった例もあったと報告されています。
  • Cairn（Webサイトの大量侵害）：セキュリティ企業NorForgeが見つけ、ロイターが10月19日ごろ報道。1人の攻撃者がオープンソースのAIエージェント基盤Cairnを使い、1,200を超えるサイトを攻撃して100社以上に侵入したとされます。費用はトークン代で約5,000ドル、侵入1件あたり約50ドルという推計です。

2. 攻撃者の動きとAI

2.1 AIは「相談相手」から「攻撃を回す側」へ

Anthropicが2026年9月10日に公表した脅威インテリジェンスレポート（2025年12月〜2026年8月に阻止した悪用をまとめたもの）は、攻撃者がAIをチャットの相談相手として使う段階から、攻撃の複数の段階をつなぐオーケストレーターとして使う段階へ移っていると述べています。偵察、脆弱性の悪用、データの窃取を並行して進める自律的な運用の例も挙げられています。一方で、標的の選定、成果の換金、結果の確認といった判断は、今も人が担っているとしています。

Verizonの2026年版DBIRも、攻撃者が標的の選定、初期侵入、脆弱性調査、マルウェア開発に生成AIを使っていると報告しています。AIの登場で何が根本から変わったというより、これまでの攻撃が安く・速く・大量にできるようになった、という捉え方が各レポートに共通しています。

2.2 ARTEX

2026年10月の報告で名前が挙がったツールの代表がARTEXです。CrowdStrikeやMicrosoft、CSA（Cloud Security Alliance）の資料によると、次のようなものです。

  • 2026年7月26日に、AGPL-3.0のオープンソースとして公開された
  • 複数のAIエージェントが、偵察から脆弱性の発見、攻撃経路の検討までを進める、ペネトレーションテストの自動化基盤である
  • それ自体はAIモデルではなく、外部のLLMとツールを呼び出して組み合わせる「指揮役」にあたる
  • 韓国の金融機関、日本企業、ConnectWise経由のサプライチェーン攻撃で、実際に使われたと報告された

開発者は悪用を理由に、2026年10月8日にソースコードを非公開にしました。ただ、それまでに出回ったコピーやフォーク（派生版）は残っており、攻撃に使える状態が続いています。AhnLabは、世界で約600のIPアドレスでARTEXのインスタンスを確認したとしています。

2.3 高度な派生版の広がり

本家が止まっても、派生版で機能が足されていくのが、このツールの厄介なところです。報道では、派生版の1つ（開発者アカウント名から「RUBAT-B」と呼ばれています）に、公開サーバーからDMZ、内部ネットワーク、Active Directory（AD）へと段階的に進む機能が加わったと伝えられています。防御寄りに改造した派生版もあり、同じ仕組みを守る側も使えます。

攻撃の自動化は、「外部に公開されたサーバーを破る」だけでなく、「その先、内部まで進む」ところまで広がっています。

fig_layers.png

従来の「インターネットに面したところを固めれば内部は安全」という前提では足りません。公開サーバーが一度破られると、そのサーバーに許された内部への通信や、内部に残った古い脆弱性が、次の足場になります。対策は「外側で止める」と「入られても広げない」の二段構えで考える必要があります（具体的な対策は4.7で扱います）。

2.4 攻撃箇所は既知の脆弱性やセキュリティの弱さ

一連の事案で狙われたのは、特別な未知の脆弱性（ゼロデイ）ではなく、次のような以前からある弱点でした。

  • 認証が弱い公開システム
  • 設定ファイルに置かれた秘密情報
  • APIの認可の不備
  • 公開されてから放置された既知の脆弱性

GMOインターネットのFX向けVPSへの不正アクセス（6章で後述）でも、会社自身が、事前に社内で把握・指摘されていたセキュリティ上の課題を突かれたと説明しています。未知の脆弱性にやられたというより、自社で認識していた弱点が残っていた、というパターンです。

変わったのは、攻撃の「コスト」と「速さ」です。かつては、こうした弱点を一つひとつ探すには手間がかかり、割に合わない標的は見逃されていました。AIエージェントは、その探索を安く（Cairnの例では1件約50ドル）、大量に、休みなく行えます。CrowdStrikeは、公開PoCがある脆弱性の悪用の88%がPoC公開から48時間以内に起きていると報告しています。

つまり、やるべきことの多くは以前から知られている基本の対策です。変わったのは、その基本を毎回・速く回さないと間に合わなくなった点です。

3. 現状の対策とその限界

多くの組織の対策は、次の3つの組み合わせだと思います。

  • 脆弱性スキャナーやベンダーの情報による脆弱性の検知
  • 定期メンテナンスなどでの手動のパッチ適用
  • リリース前や年1回の外部ペネトレーションテスト

どれも必要な対策です。ただ、直近の攻撃と比べると、これだけでは拾えないものが4つあります。

3.1 スピードが合わない

攻撃側 防御側
脆弱性が公開されてから 公開PoCのある脆弱性の悪用の88%が、PoC公開から48時間以内（CrowdStrike、2026年1〜6月）。悪用までの平均は推定 −7日で、パッチより先に悪用が始まっている（Mandiant M-Trends 2026） 悪用が確認された脆弱性（CISA KEV）でも、完全に修正できたのは26%。修正までの中央値は43日（Verizon DBIR 2026）
侵入してから 標的にしてから特権を得るまで3時間未満の例（Microsoft、ARTEXを使った攻撃） アルカディアの事案では、攻撃開始から検知まで約17時間
試すコスト AIエージェントを使った攻撃で、侵入1件あたりのトークン代は約50ドルという推計（NorForge、Cairnの事例） 外部のペネトレーションテストは年1回などのその断面での検査、継続的に実施はするもののAIの進化のスピードにおいつけない

年1回のペネトレーションテストは、その時点の状態しか見ていません。次のリリースで入った脆弱性や、テストの翌週に公開されたCVEは、次の検査まで残ります。

3.2 自社のコードと設定の穴は、CVEのスキャンでは見つからない

脆弱性スキャナーが得意なのは、CVEが割り当てられた製品やライブラリです。アルカディアの事案の原因は、自社のメディアサーバーのディレクトリパストラバーサルと、設定ファイルに置かれたサービス間のシークレットキーでした。JPCERT/CCの注意喚起も、APIのアクセス制御の不備や、環境設定ファイル・バックアップファイルの放置を挙げています。どれも製品のCVEとしては出てきません。

3.3 委託先や共通基盤から被害が広がる

国内の事案では、問い合わせシステムの提供元、クラウド基盤、メール配信基盤への攻撃が、それを使う複数の企業に波及しました。Verizon DBIR 2026でも、第三者が関わる侵害は全体の48%で、前年から60%増えています。自社のシステムだけを見ていると、この経路は抜け落ちます。

3.4 外側だけを守る前提が崩れている

「インターネットに面したところを固めれば内部は安全」という考え方は今もよく見かけます。内部のサーバーはパッチを後回しにする運用も珍しくありません。しかし直近の事例では、外側を破られた後に内部へ進まれています。

  • デジタル庁のGSSでは、VPN機器の脆弱性から入られ、保守運用担当者のアカウントでサーバー上の大量のファイルにアクセスされた
  • ConnectWiseの事案では、侵入後にアプリの資格情報の追加や特権ロールの変更が行われた（Microsoft）
  • ARTEXの派生版には、公開サーバーからDMZ、内部、ADへと段階的に進む機能が加わったと報じられている

外側が一度破られると、内部に残った古い脆弱性や広すぎる権限が、そのまま次の足場になります。

4. 今後やるべきこと（技術）

攻撃が安く速くなった以上、防御側も同じ速さで回る仕組みが要ります。とはいえ、まず基本の対策を固めることが最優先です。ここでのAIは、基本の対策をコミットやデプロイのたびに回すための手段として扱います。

fig_pipeline.png

工程 やること AIに任せる部分 人が持つ部分
設計・コーディング 脅威モデリング、脆弱性チェック、静的解析（SAST）、シークレット検出 脅威モデルの生成、PRごとのコードレビュー モデルと指摘の確認
ビルド SBOM生成、依存ライブラリの管理、コンテナイメージのチェック — 例外の承認
テスト 検証環境での動的解析（DAST）とペネトレーションテスト AIペネトレーションテスト 範囲と許可の管理
修正テスト 修正コードの作成と再テスト 修正PRの作成、再テスト レビューとマージ
承認・デプロイ 重大な問題が残っていないかの判定、設定値・IaCのチェック — 最終承認
運用・継続監視 振る舞いの監視、新しいCVEの影響確認 異常検知、一次調査 対応の判断

4.1 コーディング：AIのコードレビューを毎回のPRで回す

AIによるコードの脆弱性診断は、2026年に入って製品化が進みました。Claude Security（Anthropic）、Codex Security（OpenAI）、GitHub Copilot Autofix、Amazon Inspector Code Security、AWS Continuumなどがあります。アルカディアも再発防止策として、全サービスで社内のLLMを使った脆弱性診断とコードレビューを実施しています。

使うときの注意点は次の3つです。

  • 年に一度ではなく、PRごとに回す
  • 既存のSAST、依存関係のスキャン、シークレット検出と併用する。AIのレビューに置き換えない
  • 指摘は人が確認する。CERT-EUも、AIを使ったテストは人が結果を検証する前提で使うよう勧めています

4.2 ビルド：SBOM、依存ライブラリ、コンテナイメージ

SBOM（ソフトウェア部品表）は、ソフトウェアに含まれるOSSやライブラリの一覧です。これがあると、新しいCVEが出たときに「どのサービスのどのイメージに、その部品が入っているか」をすぐ引けます。悪用まで48時間という状況では、影響範囲の調査に1日かける余裕はありません。

  • SBOMを記録する標準フォーマットには、CycloneDXとSPDXの2つがあり、広く使われています。作り方や運用の進め方は、経済産業省の「SBOMの導入に関する手引」などにまとまっています。まずは主要なサービスでSBOMを出力し、脆弱性情報と突き合わせる運用から始めるとよいでしょう。
  • 依存しているOSSそのものが狙われる、サプライチェーン攻撃にも備えます。正規のライブラリや配布経路が乗っ取られ、利用者が気づかないまま悪性コードを取り込まされる攻撃です。2026年には、広く使われるnpmパッケージが侵害された事例（AWSが北朝鮮系の関与を特定）がありました。対策の1つが「クールダウン」で、公開直後の汚染されたバージョンを避けるため、新しいパッケージは一定時間が経つまで取り込みません（AWSはAmazon Linuxで、公開から24時間以内のnpm・pipパッケージを避ける設定を紹介しています）。
  • コンテナイメージは、OSパッケージと言語ライブラリの脆弱性に加えて、設定値（rootでの実行、不要なパッケージ、イメージ内のシークレット）も見ます。

4.3 テスト：検証環境でAIペネトレーションテストを回す

攻撃側がAIペネトレーションツールを使っている以上、防御側も同じ種類の道具でリリース前に試しておく意味があります。マネージドサービス（AWS Security Agent。現在はAWS Continuumのペネトレーションテスト）、商用サービス、OSSと、選択肢は増えています。

運用では次の点に気をつけます（CSAの推奨を参考にしています）。

  • 許可された範囲で、分離した検証環境で、ルールを文書にしてから実行する
  • ツールを動かすホスト、テスト用の認証情報、実行ログを管理する
  • OSSを使うなら、出所を確認したものに限る。攻撃に使われたツールのフォークには、管理画面を隠す機能などが追加されたものもあります

専門家による診断をなくすというわけではなく、AIペネトレーションテストはリリースごとに回す検査として位置づけます。

4.4 修正テスト：修正PRと再テストを自動化する

AIが修正のPRを作る機能は、AWS Continuum、GitHub Copilot Autofix、Claude Securityなどにあります。自動化の範囲は段階的に広げるのが現実的です。AWS Continuumは、最初は人が修正を承認するモードで始め、テストのカバレッジや適用範囲などの条件を満たした種類の修正だけを自動適用に移せる設計です。同サービスのコンソールにも、パッチが生成されたことは修正済みを意味しない、という趣旨の注記があります。

修正したら同じ検査を再実行し、塞がったことを確かめるところまでをパイプラインに入れます。

4.5 承認・デプロイ：ゲート、シークレット、設定値

  • 重大な脆弱性が残っていればデプロイを止めるゲートを置く
  • シークレットはコードや設定ファイルに書かず、シークレット管理サービスに置く。サービスごとに分け、ローテーションを前提にする。アルカディアの事案では、設定ファイルにあったサービス間のシークレットキーが侵入の足がかりになりました
  • IaCとデプロイ先の設定値をチェックする

4.6 運用・継続監視：振る舞いを見る

アルカディアの事案では、攻撃者が約10時間かけて探索していた段階では気づけず、検知のきっかけはDBの異常な負荷でした。探索の段階で気づくには、既知の攻撃パターンだけでなく振る舞いを見る必要があります。

  • Mandiantは、エッジ機器への不正アクセス、APIの大量操作、SaaS連携トークンの不審な使い方を振る舞いとして検知するよう勧めています
  • AIエージェントによる探索は、短時間に大量で体系的なリクエスト、エラーへの素早い繰り返し、多様な攻撃の試行として現れます（CSA）。WAFとボット対策をこの動きに合わせて調整します
  • JPCERT/CCは、APIのリクエスト数の制限、ログイン・パスワードリセット・SMS送信・検索といった高リスクの機能への個別の制限、利用地域が限られるサービスでの地域制限を挙げています
  • SBOMと組み合わせ、運用中のイメージに新しいCVEが出たら通知します
  • ログは90日より長く残します（Mandiant）
  • 検知結果の一次調査はAIに任せられるようになってきました（例: Amazon GuardDuty investigation agent、2026年10月時点でプレビュー）。対応の判断は人が持ちます

4.7 入られても広げない

2.3で触れた「外側で止める」と「入られても広げない」の二段構え（前掲の図）のうち、後者にあたる対策です。

考え方の軸は、「境界の内側なら信頼する」をやめることです。境界型の防御は、外周を越えられた瞬間に内部が無防備になります。代わりに、通信・アクセスのたびに「誰が・どの端末で・何に」を確認し、必要な分だけ許可する。これがゼロトラストの基本です。「一度入れたら信頼する」のではなく、リクエストごとに認証と認可をやり直す、と考えると分かりやすいと思います。

具体的には次のものがあります。

  • 公開側から内部への通信許可を棚卸しする。DMZなど公開側のサーバーが乗っ取られると、そのサーバーに許されている内部への通信が次の足場になります。許可は業務に必要なものだけに絞ります
  • 管理者と保守運用のアカウントにMFAと最小権限を適用する。普段使わない権限は必要なときだけ付与します
  • 認証情報はサービスごとに分ける。アルカディアも再発防止策として実施しています
  • AD・認証基盤の設定を点検する。Mandiantは、AD証明書サービスのテンプレートの設定ミスから管理者アカウントが作られた例を挙げています
  • 内部の資産にもパッチを当てます。優先度は下げても、対象からは外しません
  • 内部の通信とアカウントの振る舞いを監視します。GSSでは、保守運用アカウントによる大量のファイルアクセスが検知のきっかけでした
  • 外部からの接続は、VPNでネットワークに入れる方式から、利用者と端末をアクセスのたびに確かめる方式（ゼロトラスト）に寄せます

なお、デジタル庁のQ&Aによると、GSSはゼロトラストアーキテクチャを採用していました。それでも保守運用のためのVPN機器が入口になっています。ゼロトラストは導入すれば終わりではありません。保守経路のような例外の経路も、同じ基準で扱う必要があります。

4.8 パッチの優先度：CVSSと外部公開だけで決めない

パッチの優先度を「CVSSが高いか」と「インターネットに公開しているか」で決める運用は多いと思います。デジタル庁GSSの事案は、それでは足りないことを示しています。

デジタル庁のQ&A（2026年9月12日更新）では、次のように説明されています。

  • 悪用された脆弱性は、公表時の評価では「中（CVSS値Mediumレベル）」だった
  • 評価に応じた一般的な対応より早く対処を進めていたが、修正プログラムの適用前に悪用された
  • 今後は、より実質的なリスクに基づいて迅速かつ先行的に対応できるよう、脆弱性管理を強化する

デジタル庁は製品名もCVE番号も公表していません。セキュリティブログのpiyologは、Palo Alto NetworksのVPN製品の認証回避の脆弱性CVE-2026-0257に該当する可能性を挙げています。これは推測で、デジタル庁は認めていません。この脆弱性の経過は次のとおりです。

日付（2026年） 出来事
5月13日 公表。CVSS 4.7（Medium）
5月17日 悪用の観測が始まる
5月29日 研究者が技術分析を公開し、CVSSが7.8（High）に引き上げ。同じ日にCISAがKEVに登録

仮にこのCVEだったとすると、公表から4日で悪用が始まり、点数が上がったのは16日後です。公表時の点数で期限を決めていれば、点数が上がる前に攻撃が始まっていたことになります。VPNがインターネットに面していることは最初からわかっていたはずなので、「外部公開か」でも判断はつきません。

点数と外部公開のほかに、次の順で見るとよいでしょう。

fig_patch_priority.png

  1. 悪用されているか。ベンダーや脅威情報の報告、KEV、悪用を自動化しやすいか、攻撃コードが出回っているか。KEVへの登録を待つと遅いこともある
  2. 突破されたら何が手に入るか。VPNやエッジ機器は内部への入口で、保守アカウントや認証基盤につながっている
  3. どこから届くか。インターネットから届くものが先。ただし内部の資産も、外側が破られれば届く
  4. 自社の構成で該当するか。特定の設定のときだけ影響する脆弱性もある
  5. 深刻度（CVSS）。点数は後から変わるので、公表後も追う
  6. 当てた後に、すでに侵入されていないかを確かめる

公的な枠組みも同じ方向に変わっています。

  • CISAは2026年6月10日のBOD 26-04で、KEVに載った脆弱性に一律の期限を課すやり方をやめました。外部に公開されているか、KEVに載っているか、悪用を自動化できるか、悪用されたときにシステムを完全に制御されるか、の4つの組み合わせで期限を決めます。最も急ぐ区分は3日以内の修正に加え、侵害されていないかの確認を求めます。リスクの低いものは次の定期更新まで待てます。条件が変われば期限も変わります。米国の連邦政府機関向けの指令ですが、民間でも考え方は参考になります
  • 国家サイバー統括室は6月12日に政府機関向けのガイドラインを改定し、脆弱性対策を強化しました。PwCの解説によると、対応を急ぐかの判断に悪用の実績（KEV）、悪用の可能性（EPSS）、深刻度（CVSS）、資産の重要度を使うこと、パッチをすぐ当てられないときは被害が出る前にシステムを止めることも検討し、その判断基準をあらかじめ決めておくことが示されています

4.9 ツール自体もサプライチェーンの一部

2026年3月、コンテナスキャナーTrivyのGitHub Actionが侵害され、ほぼすべてのバージョンタグに悪性のコードが入れられました。CI/CDのシークレットを盗んでから通常のスキャンを実行するため、パイプラインは正常に動いているように見えました。原因は、2月に起きた別の侵害の後、認証情報のローテーションが不完全だったことだと報告されています。

  • GitHub Actionsはタグではなくコミットハッシュで固定する
  • セキュリティツールやAIツールも、ほかの依存関係と同じように管理する
  • AIツールに渡す権限と認証情報は最小にする

5. AWSでの構成例

fig_aws.png

2026年10月時点のサービスで4章の工程を組むと、次のようになります。

工程 サービス・機能 状況
コーディング Amazon Inspector Code Security（GitHub・GitLabと連携し、SAST、依存関係、IaCを検査） 提供中
コーディング AWS Continuum for code vulnerabilities（コードとAWS環境から攻撃経路を把握し、影響の大きさで優先度を付け、サンドボックスで悪用できるかを確かめ、修正PRを作る） 2026年10月22日にGA
ビルド AWS CodeArtifact（パッケージの取り込み元を一本化。パッケージオリジンコントロールで社内パッケージの置き換えを防ぐ） 提供中
ビルド Amazon ECR + Amazon Inspector（イメージの検査。新しいCVEが出ると自動で再検査） 提供中
ビルド AWS CodePipeline の InspectorScan アクション、Inspector SBOM Generator 提供中
ビルド Inspector の SBOM エクスポート（CycloneDX・SPDX形式でS3へ出力し、Athenaで集計） 提供中
テスト AWS Continuum のペネトレーションテスト（旧AWS Security Agent。VPC内のエンドポイントも対象にでき、悪用できた証拠つきで結果を返す） Security Agentとして2026年3月31日にGA
修正テスト Continuum の修正PR（最初は人の承認が必須） Continuum GAに含まれる
承認・デプロイ CodePipeline の手動承認、Inspector の重大度によるパイプラインの停止 提供中
デプロイ AWS Secrets Manager、AWS Config 提供中
運用・継続監視 Amazon GuardDuty と Extended Threat Detection（複数のシグナルを一連の攻撃としてまとめる） 提供中
運用・継続監視 GuardDuty investigation agent（検知結果を調べ、リスクと対処を報告する） プレビュー
運用・継続監視 AWS WAF（レート制限、Bot Control） 提供中
運用・継続監視 AWS Security Hub（検知結果の集約） 提供中

権限とアクセス制御（全工程にまたがる）

4.7の「入られても広げない」と、APIの認可の不備（1.2のA2B攻撃）は、権限とアクセス制御の設計で効いてきます。これは特定の工程ではなく、全体にかかるものです。

役割 サービス・機能
最小権限でのアクセス管理 AWS IAM、IAM Identity Center
過剰な権限・使われていない権限の洗い出し IAM Access Analyzer
APIの認証・認可、きめ細かい認可 API Gateway のオーソライザー（Amazon Cognito / Lambda）、Amazon Verified Permissions（Cedar で認可を記述）
VPNなしのゼロトラストアクセス（利用者と端末を都度確認） Amazon Verified Access

APIの認可は、入口で「誰が・何に」アクセスできるかを明示的に決め、非公開のエンドポイントも含めて検査するのが基本です（JPCERT/CCの推奨とも重なります）。保守・運用のアクセスは、VPNで内部ネットワークごと通すのではなく、Verified Access のように利用者と端末を都度確認する方式に寄せると、1.3のGSSのような保守経路からの侵入を抑えられます。

APIの認証・認可の流れを、もう少し細かく見ておきます。

fig_api_authz.png

ポイントは、認証（誰か）と認可（何にアクセスできるか）は別物だということです。ログイン（認証）が通っていても、認可が甘いと、リクエストのIDを書き換えて他人のデータにアクセスされます。これが認可の不備（IDOR / BOLA）で、1.2で触れたNICTの「A2B攻撃」が狙ったのもこの部分です。認証で止めず、認可の段で「そのリクエストの主体が、そのリソースの所有者か」を必ず確認します。AWSでは、API Gateway のオーソライザー（Cognito / Lambda）で認証を、Verified Permissions（Cedar）できめ細かい認可を担えます。

参考までに、アルカディアの事案で原因になった点を、AWSのどの機能で止める・気づくかに当てはめると次のようになります。アルカディアがAWSを使っていたかはわかりません。同じ構成をAWSで組むなら、という仮定の話です。

原因になった点 止める・気づく手段
メディアサーバーのパストラバーサル Inspector Code Security、Continuum のコード検査とペネトレーションテスト
設定ファイルにあったサービス間のシークレットキー Secrets Manager。サービスごとに分け、IAM で最小権限にする
アカウントIDへの総当たりでログイン成立 WAF のレート制限と Bot Control、GuardDuty、MFA。保守アクセスは Verified Access で都度確認
WordPress への不正なプラグインの追加 運用中の Inspector の検査、ホスト側のファイル改ざん検知、GuardDuty Runtime Monitoring での不審なプロセスの検知
DBのパスワード変更で外部連携が止まった Secrets Manager で接続情報を一元管理し、ローテーションを前提にした設計にする

6. 組織としての判断・連携・訓練

技術の対策を整えても、重大な脆弱性が公表されてから数時間で判断を迫られる場面はなくなりません。そこで効くのは、判断の基準と手順を平時に決めておくことです。2026年10月のPHPの脆弱性で、それがよく機能した例がありました。
fig_org.png

PHP2Shell とコドモンの対応

10月21日、PHP本体の脆弱性2件（CVE-2026-109618、CVE-2026-109619、通称PHP2Shell）が公表されました。認証なしでサーバー上のコードを実行されるおそれがあり、CVSS v4.0は9.2（Critical）です。PHPの開発チームは修正版の公開予定を事前に告知していましたが、公開前に情報が広まりました。IPAも同日に注意喚起を出し、修正版をすぐ適用できるよう準備することや、停止も見据えた連絡手順の確認を呼びかけています。

保育・教育施設向けのサービスを提供するコドモンは、この日の日中に予防的にサービスを止めました。同社の振り返り記事から、時系列を抜き出します。

時刻（10月21日） 出来事
4:33 PHPの開発チームが脆弱性と修正版の公開予定（23時）を発表
9:01 社内で把握
10:32 経営メンバーに共有。この時点では止めずに修正版を待つ方針
10:57 社内のシステムトラブル対応フローを開始
11:37 「23時の修正版公開に合わせ、事前に告知して夜間に止める。前倒しになったら即停止」で合意。前倒し時の停止は社長らが承認済み
12:03 攻撃の条件が広まり、23時より前に攻撃が成立するおそれが出る
12:37 緊急停止を決定
14:49 対象サービスの停止が完了
22:38 PHPの修正版が公開
10月22日 3:22 主要サービスを再開

状況が変わってから停止を決めるまで約30分でした。記事からは、判断を速くした要素が読み取れます。

  • 判断の軸を「子どもの情報を守ること」と決めていた
  • 前倒しになったときの停止を、事前に承認しておいた
  • 代わりの案（設定変更による緩和、一部だけの停止、監視を強めて検知してから止める）を短時間で比べ、採らない理由まで整理した
  • 配布元のパッケージが遅れる場合に備えて、自前でのビルドを並行して準備した
  • 開発、SRE、カスタマーサポート、広報、リスク管理、経営が同じ場で動いた

反省点も率直に書かれています。システムごとにPHPをどこから入手しているか（配布元は4つあった）を平時に整理していなかったこと、構成の違う一部のシステムが準備から漏れたこと、予防的な停止だと伝わる案内文を用意していなかったこと、停止したときの業務への影響を事前に整理していなかったこと、です。1つ目は4.2のSBOMと依存関係の管理の話そのものです。

経営層が優先度を判断する

有事の判断だけでなく、平時に「現場の指摘にどこまで優先度を付けるか」も、組織の判断の問題です。GMOインターネットが2026年10月に公表したFX向けVPS「お名前.com デスクトップクラウド」への不正アクセスは、ここを考えさせる事案でした。国内外70社以上のFX・証券の取引口座で不正操作が起き、対象となりうるサーバーは26,739件とされています。

代表の熊谷氏が公表した文章によると、このサービスのセキュリティ上の課題は、社内のホワイトハッカーから事前に現場へ指摘されており、現場チームも対策を進めていました。ただ、サービス可用性への影響や他の対処との優先順位を踏まえた結果、「その対応の深度とスピードが十分ではなく、攻撃者にその間隙を突かれてしまいました」と説明しています。「プロを抱えながら、その知見を組織として完璧に防御へ昇華しきれなかった」とも述べています。

ここから読み取れるのは、指摘が上がっていても、可用性や他の業務との優先順位をどう付けるかで、対応が間に合うかどうかが変わるということです。現場は、止めると業務に響く対策を自分の判断だけでは進めにくいものです。だからこそ、こうした指摘が上がったときに、リスクと可用性を天秤にかけて「どこまでを・いつまでに」やるかを決め、必要なら可用性より先に手当てするよう現場に指示するのは、経営層の役割になります。4.8のパッチの優先度と同じ考え方を、組織の意思決定として持っておく、ということです。

平時にやっておくこと

  • 決めておく: 判断の軸、予防停止の条件と承認者、連絡先と連絡手順、利用者向けの案内文のひな形、停止中の代替手段
  • 把握しておく: どのシステムが何に依存し、どこから更新を受け取っているか（SBOM、構成管理、認証情報の依存関係）
  • 訓練する: 「重大な脆弱性が公表され、修正版が出る前に攻撃の条件が広まった」という想定で、判断、連絡、停止、再開までを一通り演習する

7. まとめ

2026年秋のインシデントが示したのは、特別な新手の攻撃ではありません。認証の弱い公開システム、設定ファイルの秘密情報、APIの認可不備、放置された既知の脆弱性といった、以前からある弱点が狙われました。変わったのは、AIによって攻撃が安く・速く・大量になった点です。

だから防御側も、基本の対策を毎回のリリースで速く回し、外側で止めるだけでなく入られても広げない備えを持ち、パッチは多面的に優先度を付け、技術だけでなく組織の判断と訓練までを前提にする必要があります。

最後に、まず手をつけることを挙げます。

  1. インターネットに公開しているもの（Webアプリ、API、管理画面、VPN、古いアプリケーション）を棚卸しし、使っていないものを止める
  2. APIのリクエスト数の制限と、非公開のAPIも含めた認可の不備を点検する
  3. コードや設定ファイルからシークレットを外し、サービスごとに分ける
  4. 公開側から内部への通信許可と、管理者・保守運用アカウントの権限とMFAを見直す
  5. パッチの優先度を「悪用されているか」「突破されたら何が手に入るか」で決め直し、適用後は侵害の痕跡を確かめる
  6. SBOMと依存関係の入手経路を整理し、重大な脆弱性が出たときの停止判断と連絡手順を決めて、一度訓練する
  7. ログを90日より長く残し、自動化ツールらしい探索に気づけるようにする

参考資料

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?