2026年7月26日
SaaSセキュリティリーグ 諸角昌宏
第7回SaaSセキュリティリーグ会議
「SaaSセキュリティリーグ」は、SaaSユーザー企業の実務者同士で情報交換を行う取り組みである。SaaS管理者やセキュリティ担当者を横串でつなぎ、知見交換を行うことで、セキュリティレベル向上に貢献していくことを目的としている。ここでは、「SaaSセキュリティリーグ」が行った第7回会議の内容をまとめて公開する。なお、今回は会議の内容をベースに情報セキュリティの基本対策について筆者の考えとしてまとめた。
議論の概要
フロンティアAI（高性能AI）がシステムの脆弱性を短期間・大量に自動発見する能力を持ち始め、サイバー攻撃の質と速度が根本的に変容しつつある。大量パッチが一斉提供される事態を想定した早期対応が急務と判断。金融庁と日本銀行が連名で金融機関等に緊急要請を発出した（https://www.fsa.go.jp/news/r7/sonota/20260522-5/01.pdf）。
今回のSaaSセキュリティリーグでは、この要請の内容をもとに、フロンティアAI脅威対応を検討する情報システム部門の方々でディスカッションを行った。
金融庁と日本銀行による要請の概要
以下、9項目について、おおむね1か月以内に対応することが求められた。
- 経営課題として位置づけ
フロンティアAIへの対応を経営上の優先事項とし、経営層が直接指揮・関与する体制を構築する。IT・セキュリティ部門任せにせず、経営トップが全社的課題として主導する。CIO・CISOら経営層が対応方針の策定から状況把握まで継続的に関与すること。 - 優先対象システムの特定
社会的影響が大きいサービス・システムを優先リストアップし、対応順位を明確化する。リソース拡充には限界があるため、リスクベースで優先度を決める。特にインターネットバンキング等、重要業務を支える外部公開システムを最優先とし、共同運営システムでは責任分担を事前に明確化する。 - 技術的負債の解消
優先対象のEOS製品・脆弱構成・サポート切れソフトウェアを洗い出し排除する。2で特定したシステムのソフトウェア・ネットワーク構成を再確認し、脆弱性発見時に即座に対象を特定できる状態にする。不要ポートの閉塞、特権IDの削除、サポート終了製品の更新なども実施。 - パッチ適用人員の確保
大量パッチ適用を短期間で処理できる人的リソースを追加・再配置する。他部門からの応援も含め人員を増強し、ベンダー側のリソース確保状況も事前に確認する。脆弱性の優先度評価体制も併せて強化する。 - ベンダー契約の確認
保守契約のSLA・パッチ提供範囲・対応時間を確認し不備があれば改定交渉する。パッチ適用が契約範囲・役割分担に含まれているか、夜間・休日対応が可能か、SLA/SLOが遵守できるリソースがベンダー側にあるかを確認。ひっ迫時の絞り込みやリスク受容プロセスも整備する。 - リスクベースのパッチ運用
CVSSスコア一辺倒を脱却。自社システムへの影響度・攻撃可能性を加味して優先付けする。CVSSスコアだけでなく攻撃成立の蓋然性も踏まえて優先順位を判断する。パッチ適用前テストについても、障害リスクと未適用リスクを比較し、合理的な縮小を検討する。 - 多層防御の強化
パッチ適用以外の手段（WAF・ネットワーク分離・特権アクセス制限等）も並行強化する。パッチ適用が困難・遅延する場合、WAFによる仮想パッチ、ボット対策、ネットワーク分離、特権IDへの多要素認証、EDR等の多層防御で補う。これらは恒久策ではなく、残存リスクを踏まえたリスク受容手続が必要。 - BCP・代替手段の整備
優先サービスの停止を前提にしたBCPを見直し、代替手段・縮退運転の手順を整備する。防御が破られる可能性を前提に、能動的なシステム停止の判断基準・手順をあらかじめ検討。BCPの有効性、顧客対応手順、緊急連絡体制も点検する。テスト縮小に伴う障害増加やサードパーティ製品の停止リスクにも備える。 - 外部連携の強化
NISC・金融ISAC等との情報共有体制を維持・強化し、早期警戒情報を活用する。金融ISAC、業界団体、当局等から情報を積極的に収集する。自組織の対応状況も共助コミュニティで共有し、業界全体の強靭性向上に貢献する。
ディスカッションポイント
ここでは、SaaSセキュリティリーグでディスカッションされた内容をリストアップする。
- 9項目の対策は、全体的に当たり前の対策を行うことを求めている。新しく何かやっていくということではないし、特別に何かやるということではない。今まで手が回っていなかったことを、きちんと実行していくという認識である。
- パッチ適用は各オーナーの対応となっている。システム管理者の判断により、パッチにどのように対応するかが決まっている。したがって、ミュトスの前後で特に何も変わってない。
- 経営者は、ミュトスという脅威があるが具体的にどのような対策が必要なのかは理解できていない。逆に、アサヒビール、KADOKAWA、ニチレイ等の事象を脅威ベースで捉え、積極的に対策を求めている。これらの事象は、BCPあるいはレジリエンスの問題としてとらえやすいため、そのための対策を求めている。
- 9項目の要請は、基本的にセキュリティハイジーンの強化を求めている。セキュリティハイジーンは、必要性は分かっていてもなかなか実施できていないところであり、このような要請により業界の認識が高まって行けば良いと考えられる。セキュリティ部門にとっては追い風と言えるかもしれない。
- 経産省も、所管する重要インフラ事業者に対して要請をしている（https://www.nikkei.com/article/DGXZQOUA302PI0Q6A430C2000000/）。重要インフラからセキュリティハイジーンの強化が徹底されて、それがさらに一般企業に落ちてくるような流れができると、情報セキュリティのレベルの底上げにつながることが期待できる。
- 金融ISACでは、様々な角度から情報セキュリティの検討が進められている。この情報が、一般にも広められうようなことができると全体的な底上げにつながるのではないだろうか。
まとめ
ここからは、ディスカッションの内容をベースに筆者としての見解として整理してみたい。
対策9項目は、経営者と現場でなぜ十分に取り組まれてこなかったのか？
9項目について、何故対応が進まないかについて整理すると以下のようになると考えられる。あくまで、筆者としての意見であり、すべての組織に通じるものではないことを述べておく。
- 経営課題として位置づけ
経営者:具体的インシデント事例には前向きに動くが、抽象的な脅威にはなかなか動かない。「守れて当たり前」の話にお金や労力をかけたがらない。
現場: 難しい技術の話を偉い人に分かるように説明するのが大変。言われても本気で取り合ってもらえないことが多かった。 - 優先対象システムの特定
経営者: 「このシステムは後回し」とはっきり言うと、後で問題が起きたときに責められる。だから決めたがらない。
現場: 自分の部署のシステムが「後回し」にされると、予算や人員を減らされる前触れに見えて反発が起きる。 - 技術的負債の解消
経営者: 今動いているものに手を入れる投資は「無駄遣い」に見えやすく、他のことにお金を使いたがる。
現場: 古いシステムほど詳しい人がいなくなっていて、触ると壊れる不安が大きく、みんな避けてきた。 - パッチ適用人員の確保
経営者: セキュリティはお金を生まない部門なので、人を増やすことに二の足を踏みがち。
現場: パッチ適用は各オーナーが対応している状況で現状特に問題ない。適用スピードを上げた場合のリソース不足への対応は今後の検討課題。 - ベンダー契約の確認
経営者: 契約を見直すと値上げ交渉になりやすく、コストが増えるのを嫌う。
現場: 法務や調達を巻き込む面倒な手続きが必要で、今の契約の甘さがバレて気まずい思いをすることもあった。 - リスクベースのパッチ運用
経営者: テストを省いて後で障害が起きたら自分の判断ミスになるので、はっきり決めたがらない。
現場: 品質を落とす判断は技術者として抵抗があり、過去に急いで直して逆に壊れた経験もあって慎重になっている。 - 多層防御の強化
経営者: 「保険」のような投資で成果が見えにくく、後回しにされやすい。
現場: 導入すると誤警報が増えたり、既存の仕組みと合わなかったり、利用者から「面倒くさい」と文句が出たりして負担が増える。 - BCP・代替手段の整備
経営者: まだ実害が出ていない段階で自ら止める予防的な判断は、結果的に何も起きなければ「過剰対応だった」と批判されかねず、様子見をして先送りしたい。
現場: 「誰が止める判断をするのか」がはっきりしないまま、責任だけ押し付けられるのが怖い。 - 外部連携の強化
経営者: 外部との情報発信・連携は、規制当局から明確に要請されない限り動き出さない受け身の姿勢が実情。自ら進んで他業界・他組織に知見を発信していく発想が弱い。
現場: 金融ISAC等の既存コミュニティ内での情報交換自体は行われているが、そこで得た知見を組織の枠を超えて広く共有・発信するところまでは踏み込めていない。
まとめると、効果が目に見えにくい、何かあったときの責任が特定の人にのしかかる、古いシステムや知識が特定の人に頼りきりになっている、という3つの構造的な事情が根っこにあるものと考える。
具体的な対策例
ここでは、9項目の要請に対する筆者が考える代表的な実装例として以下を上げる。今後の対策、検討の参考としていただきたい。
- 経営課題として位置づけ
経営会議・取締役会での定例報告化、経営トップを本部長とする緊急対策本部の設置、CISO直轄タスクフォースの編成、対応予算の緊急予備枠確保。 - 優先対象システムの特定
外部公開資産の棚卸し(アタックサーフェス管理)、資産管理台帳(CMDB)の整備、ビジネスインパクト分析による重要度ランク付け、ネット取引・決済・顧客DB等を最優先リスト化、共同運営システムの責任分担を契約書で明文化。 - 技術的負債の解消
ソフトウェア部品管理表(SBOM)の整備、不要なポート・サービスの洗い出しと閉塞、特権IDの棚卸しと削除、EOL(サポート終了)製品のリストアップとアップグレード計画策定。 - パッチ適用人員の確保
脆弱性対応の臨時専任チーム編成、他部門からの応援ローテーション、MSSPの活用拡大、ベンダーへの増員要請と体制確認。 - ベンダー契約の確認
維持保守契約のパッチ対応条項レビュー、夜間・休日対応のSLA明記、複数組織で同時発生した場合の代替対応策の検討、クラウド事業者からの報告体制の確認。 - リスクベースのパッチ適用
CVSSに加えEPSS(悪用予測スコア)やKEV(実際に悪用済みの脆弱性リスト)を併用した優先順位付け、深刻度別のパッチ適用期限設定(重大:24時間以内、高:72時間以内など)、システムの重要度に応じたテスト範囲の簡略化ルール策定。 - 多層防御の強化
クラウド型WAFによる仮想パッチ、EDR/XDRの導入拡大、特権アカウントへの多要素認証必須化、ネットワークセグメンテーション、ボット対策(レート制限等)の導入。 - BCP・代替手段の整備
BCP/DRの机上訓練実施、能動的サービス停止の判断基準・承認フローのマニュアル化、顧客向け緊急連絡テンプレートの事前準備、緊急時エスカレーション体制の整備。 - 外部連携の強化
ISACへの加入・積極参加、業界内の脅威インテリジェンス共有会合への参加、IPA等からの情報の定期収集、自組織の対応事例の匿名化共有。
まとめのまとめ
金融機関等への緊急要請の中で触れられている「AI性能の高度化を踏まえたサイバーセキュリティ対策の強化について ～Project YATA-Shield～」では、「重要インフラ事業者等においては、高性能AIの悪用リスクに備えたサイバーセキュリティ対策の実施や、より高速かつ大量に脆弱性が発見・修正されることを前提とした対策強化を行うとともに、ベンダ等においては、高性能AIの活用を含め、より早期の脆弱性の発見・修正等の実施」を求めている。あくまで重要インフラ・防衛産業に限定された要請であるが、筆者は、一般企業へは①サプライチェーン圧力、②ベンダー主導の標準化、③インシデント報道による自主対応という経路で広がる可能性があると考える。
このような要請が一般企業に広まるかどうかに関わらず、情報セキュリティ部門にとって、この緊急要請の9項目はいままでやりたくてもなかなかできなかった基本対策やセキュリティハイジーンであるといえる。今回の要請は、これまで優先順位を上げにくかった基本対策を経営課題として位置付ける契機となり得る。セキュリティの基本対策の整備から、継続的に改善するセキュリティハイジーンに取り組むことで、組織のセキュリティレベルを大きく向上させることができるチャンスと捉えることが重要であると考える。
以上