• 2026/10/28 06:30 掲載

Claude Mythos時代の脆弱性対応…「パッチ後回し」が危ないワケと3つの計画(3/4)

会員(無料)になると、いいね!でマイページに保存できます。

新設の事例9…設計図に載らない“シャドーAPI”が狙われる

 今回のWARNINGで追加された事例に、事例9「APIが悪用される事例」がある。API(ソフトウェア同士をつなぎ、データをやり取りするための窓口)の設計・設定不備により、本来アクセスできるはずのない他者の情報が閲覧可能であったために、情報漏えいにつながった事例が紹介されている。

 事例9の原因の1つに「管理対象から漏れたAPI」が挙げられている。機能追加に伴って把握されない「シャドーAPI」は生まれやすく、設計図に載っていない以上、設計図からは見つからない。

 まずAPIゲートウェイや通信ログから、旧バージョンや検証環境も含め、実際に動いているAPIを洗い出す必要がある。

 洗い出した構成を関係者で共有するには脅威モデリング(システムに潜む脅威を図示し、対策を検討する手法)が有効だ。特に金融機関では、金融庁のサイバーセキュリティガイドラインにてセキュリティ・バイ・デザインによる安全なサービス開発が求められており、設計段階から関係者全員が共通認識を持つためのツールとしても脅威モデリングが注目されている。

 ただ、脅威モデリングの必要性は以前から認められていたものの、専門的な知識を持った人がいないと描けないなどの問題があり、あまり浸透していなかったのが実態だ。しかし近年は、「脅威モデリング・マニフェスト」の考え方が支持を集め、関係者全員で使う道具へと変わりつつある。

 脅威モデリングを描くツールとしてMicrosoft Threat Modeling Toolが有名だが、筆者も脅威モデリング・マニフェストの思想を取り入れたツール「CyberRiskScape」(注1)をOSS(オープンソースソフトウェア)として公開している。

※注1:CyberRiskScapeの解説(https://github.com/takashi-ohmoto-git/CyberRiskScape/blob/main/guide/README.ja.md)

 本ツールはサーバやAPIゲートウェイなどをドラッグ&ドロップで配置するだけで、あらかじめ登録されている脅威が自動的に表示される。情報通信研究機構(NICT)が注意喚起した「A2B攻撃」なども表現できる。

 この機会に一度、公開サービスの脅威モデリングを描き、関係者を集めて、セキュリティ対策や監視から漏れているAPIによる接続がないか点検することを推奨する。

画像
ドラッグ&ドロップで配置するだけで脅威が表示される
筆者作成の脅威モデリングツール「CyberRiskScape」。OSSのため無料で利用できる
(画像:筆者作成)

脆弱性対応で最も重要な「計画」、平時に決める3つの考慮点

 今回の不正アクセス騒動以前から、Anthropicが一部の組織に限って提供するAIモデル「Claude Mythos Preview」の発表を契機に、AIで脆弱性発見が加速する前提での対応のあり方が議論されてきた。筆者が行き着いた結論は「脆弱性対応とは計画である」というものだ。

 パッチ適用の効率化や自動化に焦点を当てた議論は頓挫しやすい。全システムを一律には扱えず、特定の認証を取得したソフトウェアのように、再認定が必要で簡単に更新できないものもあるからだ。

 組織全体のパッチ管理についてまとめられた米国立標準技術研究所(NIST)のNIST SP 800-40 Rev.4(2022年)も、脆弱性のたびにリスクを評価するのは現実的でないとし、事前の計画で意思決定を簡素化するよう求めている。平時に決めておきたいのは次の3点である。

 ■考慮点1:計画停止を設計に組み込む
 設計段階から、パッチ適用のための停止と作業工程を前提にしておく。止める時間のない設計が、先延ばしを生む。

 ■考慮点2:パッチを当てられない資産は隔離する
 更新できないシステムは平時に洗い出し、ネットワーク分離などで悪用されにくい環境に置く。

 ■考慮点3:似たシステムをまとめて手順を決める
 従業員のPC、レガシー機器、重要サービスなどを性質ごとに分け、停止の制約と手順を決めておく。脆弱性の公表を待ってから考えていては、仕組み化された攻撃に間に合わない。

 これら3つの考慮点は現代の脆弱性対応を考える上で欠かせない要素であり、これらの「計画」がない状態では、技術的な自動化ツールを導入しても効果のある脆弱性対応は見込めないのだ。

 もう1つ欠かせないのが、攻撃を受けた際の緊急停止の計画だ。影響範囲が小さい停止ほど現場に委ね、大きい停止ほど基準を経営と事前に合意しておく。たとえば下表のような設計が考えられる。

停止の範囲 判断者(例) 事前に決めておくこと
個別のアカウント・端末 セキュリティ運用担当 即時・自動で実行できる条件
特定のAPI・アクセス元・セグメント CISO(最高情報セキュリティ責任者) 判断までの目標時間、事業部門への報告ルール
サービスの一部・全部 経営層(CISOが起案) 停止基準、代替手段、顧客・当局への連絡手順
停止範囲と判断者の設計例(出典:筆者作成)

 併せて再開の条件も事前に決めておく。侵入経路の封鎖、認証情報の初期化、残存活動の確認を経ずに再開すれば、再侵入を招く恐れがある。

 止める対策が流出の範囲を抑えるのに対し、データの削減は流出し得る総量を減らす。注意喚起は個人情報保護法第22条を引き、不要となった個人データの遅滞ない消去を改めて促した。

 情報処理推進機構(IPA)も、窃取情報が脅迫や不正売買に使われる二次被害の拡大を指摘し、「不要な情報は持たない」原則での再点検を求めている。 【次ページ】脆弱性対応で最も重要な「計画」、平時に決める3つの考慮点
関連タグ タグをフォローすると最新情報が表示されます
あなたの投稿

    PR

    PR

    PR

投稿したコメントを
削除しますか?

あなたの投稿コメント編集

通報

このコメントについて、
問題の詳細をお知らせください。

ビジネス+ITルール違反についてはこちらをご覧ください。

通報

報告が完了しました

コメントを投稿することにより自身の基本情報が
本メディアサイトに公開されます

基本情報公開時のサンプル画像
報告が完了しました

「」さんのブロックを解除しますか?

ブロックを解除するとお互いにフォローすることができるようになります。

ブロック

さんはあなたをフォローしたりあなたのコメントにいいねできなくなります。また、さんからの通知は表示されなくなります。

さんをブロックしますか?

ブロック

ブロックが完了しました

ブロック解除

ブロック解除が完了しました

機能制限のお知らせ

現在、コメントの違反報告があったため一部機能が利用できなくなっています。

そのため、この機能はご利用いただけません。
詳しくはこちらにお問い合わせください。

ユーザーをフォローすることにより自身の基本情報が
お相手に公開されます

基本情報公開時のサンプル画像