デジタル庁GSSに不正アクセス ―約24.6万件の情報漏洩の可能性と企業の対策

Share
デジタル庁GSSに不正アクセス ―約24.6万件の情報漏洩の可能性と企業の対策アイキャッチ画像

デジタル庁は2026年9月11日、ガバメントソリューションサービス(GSS)への不正アクセスにより、職員や業務関係者の個人情報約24.6万件が漏洩した可能性があると公表しました*1。今回の事案では、VPN機器の既知の脆弱性が悪用され、保守運用担当者のアカウントを利用した大量のファイルアクセスが検知されています。本記事では、公表情報をもとに事案の経緯と影響を整理するとともに、企業が脆弱性管理やセキュリティログ監視で見直したいポイントについて解説します。

GSS不正アクセスの検知から公表までの経緯

GSSは、デジタル庁が運用し、各府省庁などが業務に利用するサービスです。今回の調査は、6月25日に保守運用担当者のアカウントによるサーバー上の大量ファイルアクセスを検知したことから始まりました。VPN機器の脆弱性を使って第三者が侵入していたと判明したのは7月9日です。同日、当該アカウントを停止し、侵害された機器と外部との通信を遮断したと説明されています。6月25日は検知日であり、侵入開始日を示すものではありません。7月15日に個人情報保護委員会へ報告し、対象者や情報の内容の調査を進めたうえで9月11日に公表しました。

公式Q&Aによると、影響範囲や侵入経路、漏えいした可能性のある情報の特定に時間を要したとしています。公表時点では、修正プログラムの適用や関係アカウントの認証情報変更、通信遮断などの措置を実施済みで、その後、新たな不正アクセスや不審な通信は確認されておらず、政府業務への支障も生じていないと説明しています。*2。

図1:GSS不正アクセスの検知から公表まで

出典:デジタル庁「ガバメントソリューションサービスへの不正アクセスによる職員等の個人情報の漏えいの可能性について」(https://www.digital.go.jp/news/2026-0911-01)および「ガバメントソリューションサービスへの不正アクセスによる職員等の個人情報の漏えいの可能性について」に関するQ&A」(https://www.digital.go.jp/press/5fc99139-a4e2-4b7b-8b0c-d475e926143f)を基に作成

約24.6万件の個人情報が漏洩した可能性

約24.6万件の内訳は、GSS利用機関の職員や業務に携わった公務員等の情報が約18.9万件、業務に携わった事業者や個人の情報が約5.7万件です。漏洩した可能性のある個人情報には、氏名、メールアドレス、電話番号、住所などが含まれます。属性別では、氏名が約23.6万件、メールアドレスが約23.1万件、電話番号が約9.4万件、住所が約0.1万件とされています。これらの属性には重複があるため、単純に合計することはできません。

デジタル庁は、一般の国民の個人情報や、マイナンバー、金融機関口座情報、年金番号は含まれないと説明しています。ただし、公務員以外でも、関係省庁の業務に携わった企業の従業員や個人事業主などは対象に含まれます。また、約24.6万件すべてについて、外部への持ち出しが確認されたわけではありません。不正アクセスの痕跡があり、漏えいの可能性を否定できない情報も対象にした数字です。9月14日時点で確認した公表資料では、関連する二次被害は確認されていません。

深刻度「中」でも悪用

今回の脆弱性は、攻撃が確認される前に公表されていた既知の問題でした。デジタル庁は、当初の深刻度評価に応じた一般的対応より早く対処を進めたものの、修正プログラムの適用前に悪用されたと説明しています。この情報だけで、脆弱性を把握していなかった、あるいは放置していたとは判断できません。VPN製品名やCVE番号なども公表されていません。企業で見直したいのは、脆弱性の深刻度と、自社での対応優先度をつなぐ判断です。

CVSSを管理するFIRSTは、CVSSの基本評価値は脆弱性そのものの深刻度を表し、単独でリスク評価に使うべきではないと説明しています*3。利用環境や脅威の状況を加えて評価する考え方が、公式ガイドに示されています。

これを自社の運用に落とし込むなら、スコアの横に「どこから接続できる機器か」「侵害された場合に何へアクセスできるか」「業務や情報にどのような影響があるか」を記録する方法が考えられます。同じ深刻度でも、外部から接続できるVPNと、接続元を限定した機器では、確認すべき条件が異なります。これは今回のGSSの詳細構成を推定する話ではなく、自社で優先順位を判断するための実務上の整理です。パッチ適用に調整が必要な場合は、ベンダーが示す回避策や接続制限の適用可否も併せて検討します。その際、「次回メンテナンスで更新する」という予定だけで終わらせず、更新までに残るリスクと担当者、再判断の条件を記録しておくと、悪用情報が追加された際の見直しにつなげやすくなります。

図2:脆弱性対応の優先順位を考える視点

出典:FIRST「CVSS v4.0 User Guide」、デジタル庁「本事案に関するQ&A」をもとに弊社作成
※GSSの実際の運用・判断手順を示すものではありません。

保守アカウントを信頼しきらず、操作の実態を確かめる

もう一つの論点が、保守運用担当者のアカウントを通じたアクセスです。今回の公表資料では、アカウントをどのように悪用できる状態にしたのか、認証情報をどう取得したのかまでは明らかにされていません。パスワードの使い回しや多要素認証の未導入が原因だった、と断定することはできません。

企業側で検討したいのは、認証の成否に加え、アクセス後の行動を確認できる状態です。例えば、保守作業の予定と実際のアクセス時刻を照合し、対象サーバー、操作内容、ファイルへのアクセス量が作業目的と整合するかを確認する、といった運用が考えられます。大量アクセス自体には正当な作業もあるため、件数だけで不正と決めつけず、普段の利用や作業申請と照らし合わせることが大切です。その判断を支えるのが、VPNの接続記録、認証ログ、サーバーの監査ログなどです。NISTのログ管理ガイドでは、ログ管理の基盤整備や、組織全体で継続的にログを管理するプロセスの構築について示しています*4。

企業では、必要なログを取得・保存するだけでなく、複数のログを時系列で確認できる状態を整え、異常を検知した際の対応や役割分担まで含めて運用を設計することが重要です。

ゼロトラストも、日々の脆弱性管理と監視が土台になる

GSSはゼロトラストアーキテクチャを採用していたと説明されています。ただし、具体的な構成や対策は非公表です。今回の事案だけから、ゼロトラスト全体の有効性や、特定の対策が機能しなかった理由を評価することはできません。NISTはゼロトラストを、ネットワーク上の場所や資産の所有者だけで、利用者や機器を暗黙に信頼しない考え方として整理しています*5。

企業が確認すべきなのは、自社でどのアクセスを検証し、どこまでを許可し、どの記録から異常を判断できるかです。VPNの更新、アクセス権限の確認、ログ分析を、導入した製品や構成に合わせて継続する必要があります。

BBSecのログ分析・活用支援で、確認できる範囲を広げる

「ログは保存しているが、保守アカウントの不正利用をどう見つけるか決まっていない」。そうした課題には、取得対象と分析目的の整理から取り組む方法があります。BBSecの「セキュリティログ分析/活用支援」は、蓄積したログの分析から、ログ取得環境の整備に向けたコンサルティング、Splunkを用いた統合ログ管理・分析環境の構築、運用までを支援するサービスです。現状の管理ポリシー、取得状況、体制、運用プロセスを確認し、改善プランを検討しましょう。自社のVPNや認証基盤、サーバーについて、取得するログと検知したい事象を具体化すれば、追加すべき記録や運用上の課題を検討できます。既存ログの活用や分析環境の見直しを進めたい企業は、BBSecにご相談ください。

【参考情報】

編集責任:木下


セキュリティ対策についてお困りの方へ

自社のセキュリティ対策についてお悩みの場合は、ブロードバンドセキュリティ(BBSec)までお気軽にご相談ください。

ウェビナー開催のお知らせ

最新情報はこちら


Security NEWS TOPに戻る
バックナンバー TOPに戻る

Cisco FMCの脆弱性が実悪用 ―Qilinランサムウェアへの悪用事例と対策

Share
Cisco FMCの脆弱性が実悪用アイキャッチ画像

Cisco Secure Firewall Management Center(FMC)の脆弱性を悪用した攻撃が確認されています。FMCはファイアウォールなどを集中管理する製品であり、侵害された場合には、管理基盤だけでなく組織内のシステムへの影響も確認する必要があります。本記事では、FMCに影響する2件の脆弱性の概要と、実際の攻撃で確認された活動を整理し、企業が進めるべき確認と対応について解説します。

※本記事は2026年9月16日時点で公開されている情報に基づき作成しています。

Cisco FMCはファイアウォールなどを集中管理する製品

2026年9月9日、Cisco Talosは、Cisco Secure Firewall Management Center(FMC)の2件の脆弱性が実際の攻撃で悪用されていると公表しました*6。確認された攻撃活動には、FMCへの侵入後に組織内の端末へQilinランサムウェアを展開した事例も含まれています。

FMCは、Ciscoのファイアウォールや侵入防御などを集中管理するための製品です。通信の許可・遮断、アプリケーション制御、脅威への対策といったポリシーを管理し、ネットワークで起きている事象を分析する役割を持ちます*2。この役割を踏まえると、管理基盤の安全性は、配下の機器を運用するうえでの前提になります。業務用サーバーの更新計画に加え、管理者が使うセキュリティ製品そのものについても、利用バージョン、アクセス経路、管理権限を把握する必要があります。

また、「Cisco製のファイアウォールを利用している」という情報だけでは影響を判断できません。今回の対象はFMCソフトウェアなど、公式アドバイザリが指定した製品です。Ciscoは両脆弱性について、Secure Firewall ASA Software、Secure Firewall Threat Defense(FTD)Software、Firewall Device Manager(FDM)は影響を受けないとしています。管理対象の機器と、その機器を管理する製品を分けて確認しましょう。

※なおCVE-2026-20079については、Cisco Security Cloud Control(SCC)Firewall Managementも対象ですが、SaaSとしてCisco側ですでに修正済みで、ユーザーによる対応は不要とされています。

CVSS 10.0と5.3 二つの脆弱性の違い

CVE-2026-20079は、FMCのWebインターフェースにおける認証回避の脆弱性です。認証されていない遠隔の攻撃者が認証を回避し、影響を受ける装置でスクリプトを実行して、OSのroot権限を取得できる可能性があります。CVSS v3.1基本値は10.0です。rootはOSにおける強い管理権限であり、管理基盤そのものを操作される問題として受け止める必要があります。

CVE-2026-20316は、低権限アカウントの静的な認証情報が存在することに起因する脆弱性です。認証されていない遠隔の攻撃者がそのアカウントでログインし、機微なデータへアクセスできる可能性があります。CVSS v3.1基本値は5.3ですが、Ciscoは他のFMCの脆弱性と組み合わせて権限昇格に利用できることから、独自の深刻度分類では「High」と評価しています。ここで判断を誤りやすいのが、5.3という数字を見て対応を後回しにすることです。今回のように実悪用が確認され、別の問題と組み合わされると影響が広がる場合は、基本値だけでは優先順位を決められません。ベンダーによる評価の理由と、実際の攻撃での利用状況まで読むことが大切です。

図1:FMCの脆弱性悪用と侵害後の活動

Qilinランサムウェアの侵入経路は静的認証情報の悪用

Talosは、FMC上で確認した侵害後の活動を3つの群に分けています。UAT-12197はCVE-2026-20079を悪用し、Webシェルなどを設置して認証情報を窃取していました。UAT-11823では2件の脆弱性の悪用が確認され、管理対象機器の設定情報収集や、Cyclops Blinkの亜種の展開などが観測されています。Qilinランサムウェアの展開が確認されたのは、これらとは別のUAT-11988です。この群はCVE-2026-20316に関係する静的認証情報でFMCに入り、正規の組み込みツールを悪用して内部環境を調査しました。認証情報の窃取や接続経路の確保を経て、端末へQilinを展開しています。

修正プログラムの適用と侵害調査を進める

今回の対応では、FMCを修正版へアップグレードすることと、すでに侵害されていないかを確認することを分けて考える必要があります。まず、実際に運用しているFMCのバージョンを把握し、Ciscoが公開しているCVE-2026-20079とCVE-2026-20316のセキュリティアドバイザリに記載された「Fixed Software(修正版)」と照合してください。Ciscoは、これらの脆弱性への修正を含むハードニングリリースを公開しており、影響を受ける環境について、該当する修正版へのアップグレードを推奨しています。利用しているバージョンによって適切な更新先が異なるため、最新の公式アドバイザリを確認したうえで対応を進めることが重要です。さらに、すでに侵害されていないかを調べます。Ciscoは、対象ログにあるpackage_info関連の実行記録に、/var/tmp/license.tmpが含まれる場合を、悪用の可能性を示す確認ポイントとして挙げています。単に同名のファイルを探すだけではなく、公式に示されたログの文脈で確認し、侵害が疑われる場合はCisco TACへ速やかに連絡するよう求めています。

修正版へのアップグレードは今後の悪用を防ぐために重要ですが、すでに侵害されていないことを証明するものではありません。Ciscoも、侵害が疑われる場合はCisco TACへ連絡し、復旧に関する案内に従うよう求めています。「更新済み」の記録を付ける担当と、侵害の可能性を判断する担当が異なる場合は、両者の確認結果を一つの対応記録で共有すると、調査の抜けを防ぎやすくなります。

図2:修正版へのアップグレードと侵害調査 それぞれの目的

管理装置の復旧だけで対応を終えないために

侵害の疑いがあるときは、FMCだけを調べて完了とする判断は慎重に行う必要があります。今回の事例を踏まえた実務上の確認事項は、FMCで何が実行されたか、そこからどのシステムに接続できたか、認証情報の悪用がほかの環境に及んでいないか、という範囲です。これはすべての利用組織に同じ被害があるという意味ではなく、自社の接続関係と調査結果に沿って影響範囲を確かめるための考え方です。復旧を急ぐ場面でも、調査に必要なデータをどう確保するか、どこまでの通信を止めるか、どの状態をもって安全に再開できると判断するかを、保守担当者や専門家と共有する必要があります。連絡先だけでなく、判断する責任者と、判断に必要な情報を平時に定めておけば、発生後の対応に取り掛かりやすくなります。

BBSecの緊急対応支援で、調査から復旧方針の整理へ

不審なログが見つかったものの影響範囲を判断できない場合や、証拠を保全しながら復旧を進める必要がある場合には、専門的な調査や対応が必要になることがあります。BBSecでは「緊急対応支援」を通じて、初動対応やデジタルフォレンジック、原因・影響範囲の調査、復旧に向けた対応などを支援しています。緊急コンタクト窓口は24時間365日受け付けています。

また、インシデント発生に備えて平時から対応体制を整えておきたい企業向けに、「インシデントレスポンス/フォレンジック」を提供しています。契約などの確認を事前に進め、有事の初動を円滑にするための仕組みです。基本契約の締結は無償ですが、フォレンジック調査費用は含まれません。必要な支援範囲を平時から相談し、自社の対応体制につなげておくことができます。

侵害が疑われる場合は、製品固有の対応についてCiscoの案内を確認するとともに、影響範囲の調査やインシデント対応にお困りの場合は、BBSecの「緊急対応支援」へご相談ください。

緊急対応支援サービスページリンクバナー

【参考情報】

編集責任:木下


セキュリティ対策についてお困りの方へ

自社のセキュリティ対策についてお悩みの場合は、ブロードバンドセキュリティ(BBSec)までお気軽にご相談ください。

ウェビナー開催のお知らせ

最新情報はこちら


Security NEWS TOPに戻る
バックナンバー TOPに戻る

盗まれたトークンから約3時間でクラウド管理権限へ ―AnthropicのAI悪用報告から考える企業の対策

Share
AnthropicのAI悪用報告から考える企業の対策アイキャッチ画像

生成AIの活用が広がる一方で、サイバー攻撃にAIを悪用する動きも確認されています。Anthropicが2026年9月10日に公表したAI悪用の調査報告には、盗まれた開発者トークンを足掛かりに、攻撃者が被害組織のクラウド環境の完全な管理権限を約3時間で取得した事例が記されています。AIサイバー攻撃への備えを考えるうえで、この事例は、認証情報の保護と、検知後に動ける体制を点検する材料となります。

AnthropicのAI悪用報告で何が確認されたのか

今回の報告では、2025年12月から2026年8月にかけてAnthropicが検知・対処したAI悪用活動が取り上げられています。サイバー攻撃におけるAIの使われ方には幅があり、攻撃者の補助として利用された例に加え、偵察、侵入、認証情報の収集、情報窃取などをAIに実行させる例や、複数の標的に対してAIエージェントが並行して処理する例も確認されています。一方、標的の選定や攻撃結果の確認、収益化などの重要な判断には、人間が引き続き関与していたとされています。

報告には、認証情報の悪用に関する事例も複数示されています。被害組織の環境から盗んだAIサービスのAPIキーを別の攻撃に利用した例に加え、盗まれた開発者トークンを足掛かりに、被害組織のクラウド環境の完全な管理権限を約3時間で取得した事例も報告されています。認証情報は情報を盗む入口となるだけでなく、攻撃に用いるAIの計算資源へのアクセスにも利用されていました。*3

なお、約3時間という数値は、Anthropicが観測した個別の侵害事例に関するものです。すべてのAIを使った攻撃が同じ速さで進むことや、従来の攻撃より何倍速いかを示す統計ではありません。この事例から企業が考えるべきなのは、約3時間という時間そのものではなく、認証情報が悪用された場合に、異常を検知し、調査やアクセス制限などの対応へ移るまでにどの程度の時間を要するかという点です。

図1:AI悪用による侵入の個別事例

開発者トークンから管理権限取得までの個別事例
開発者トークンから管理権限取得までの個別事例
出典:Anthropic「Detecting and countering misuse of AI: September 2026」(https://www.anthropic.com/threat-intelligence-report-september-2026)を基に作成

認証情報漏洩への対策は、トークンの権限まで確認する

認証情報の管理を見直すときは、人がログインに使うパスワードに加え、アプリケーションや開発環境が使うアクセスキー、トークンも対象にします。ここからは、クラウド環境で取り組める対策をAWSの公式資料を例に整理します。前述の被害事例のクラウド事業者をAWSと特定するものではありません。

AWSはIAMの推奨事項として、一時的な認証情報の利用、多要素認証(MFA)、業務に必要な範囲に絞った権限付与、使われていない認証情報や権限の定期的な見直しを挙げています*2。システムが継続的に使う認証情報についても、長期のアクセスキーを配布する構成から、IAMロールによる一時的な認証情報へ移行できるかを検討します。自社で点検する際は、認証情報を誰が管理し、どのシステムが使い、どのデータにアクセスできるのかを確認し、用途が終わったテスト用の権限や、担当者の異動後も残る認証情報などを整理します。認証情報の保護とあわせて、必要以上の権限を与えないことが重要です。

クラウドのログは、データへの操作まで記録されているか

クラウド監視では、「ログを取得している」だけでなく、実際にどの操作まで記録されているかを確認する必要があります。例えばAWS CloudTrailでは、Amazon S3上のオブジェクトの読み取りなどはデータイベントに分類され、証跡やイベントデータストアでは初期設定で記録されないため、取得には設定と追加料金が必要です*3。自社の重要データについて、調査時に確認したい操作が記録に残るかを点検し、顧客データを保管する領域であれば、誰が、いつ、どのデータへアクセスしたかを追える設定になっているかを確認します。大量のログを一律に増やすのではなく、守るべきデータと必要な調査項目を先に決めると、取得範囲や費用も検討しやすくなります。

また、アクセスがあったという事実だけで、不正利用とは断定できません。AWSのGuardDutyの対応ガイドも、検知に関係するユーザーやロール、API操作を特定し、操作時刻や接続元IPアドレスを含めて正当な利用か確認するよう案内しています*4。担当者がこれらを照合できる情報と連絡先を持つことが、アラートを判断につなげる前提になります。

検知後は、どの認証情報の利用を止めるか判断する

認証情報の不正利用が疑われる場面では、影響するユーザーやロールと、その権限を特定する必要があります。API操作の内容を見れば、正常な処理との違いや調査すべき範囲を検討できます。確認の結果、正当な利用と判断できない場合は、該当するクラウドサービスの手順に沿って封じ込めを進めます。

ここで注意したいのが、すでに発行された一時的な認証情報の扱いです。AWSは、不正利用を止める手段として、一時的な認証情報に付与される権限の変更や、IAMロールの既存セッションの取り消し方法を説明しています*5。対象のロールを利用する正常なユーザーにも影響する場合があり、どの利用を止めるかを区別することが必要です。

緊急時の手順には、実行する操作だけでなく、その操作で停止する業務と、判断を行う担当者も記載しておきます。「認証情報を無効にする」とだけ書かれた手順を、自社のアカウントやサービスに当てはめて確認する作業です。担当部門が異なる場合も、現場で判断できる範囲をあらかじめ合意しておくことが、連絡待ちを減らすための実務的な準備になります。

図2:認証情報の悪用に備える監視と初動対応

出典:AWS「Remediating potentially compromised AWS credentials」(https://docs.aws.amazon.com/guardduty/latest/ug/compromised-creds.html)「Disabling permissions for temporary security credentials」(https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_disable-perms.html)「SEC10-BP07 Run simulations」(https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_run_game_days.html)を基に弊社作成

「対応できるはず」を訓練で確かめる

検知から対応までの時間を短くしたいなら、まず自社の手順を一度動かして確かめることです。AWSのWell-Architected Frameworkでは、インシデント対応能力を評価する方法として演習を挙げ、机上演習では関係者の役割や責任、連絡手段、手順書を確認できると説明しています。*6

例えば「夜間に、通常と異なる認証情報の利用が通知された」という場面を設定し、担当者に連絡が届くか、正当な作業かを確認できるか、アクセス制限を誰が判断するかを話し合います。これは本稿で提案する訓練の例です。連絡先の更新漏れや判断権限の曖昧さが見つかれば、実際のインシデントが起こる前に修正できます。

演習では、通知を確認した時点、調査を始めた時点、対応を決めた時点を分けて記録すると、改善すべき箇所を具体化できます。約3時間という他社事例をそのまま自社の目標時間にするのではなく、自社の重要業務と運用体制に即して、対応を遅らせる要因を取り除くことが大切です。


監視からインシデント対応まで、セキュリティ体制を見直したい企業へ

こうした体制を自社だけで維持することが難しい場合は、監視や分析、対応を専門家と分担する方法があります。ブロードバンドセキュリティ(BBSec)の「G-MDR®」では、セキュリティ対策を統合的に監視・相関分析し、専門エンジニアが24時間365日体制で監視・運用を支援します。アラートの検知だけでなく、その後の調査や対応を含めたセキュリティ体制についてもご相談いただけます。

※外部サイトにリンクします。

セキュリティ対策について相談する

「アラートは検知できても、その後の調査や対応に不安がある」「24時間365日の監視体制を整えたい」といった課題がある場合は、BBSecまでお気軽にご相談ください。

導入を検討する際は、自社のクラウド環境や既存製品から連携できるログ、検知後に実行する対応、社内の承認が必要な操作を具体的に相談するとよいでしょう。すべてのクラウドサービスや復旧作業が無条件に対象になると考えず、自社に必要な監視範囲と対応範囲を確認することが大切です。


【参考情報】

編集責任:木下


ウェビナー開催のお知らせ

最新情報はこちら


Security NEWS TOPに戻る
バックナンバー TOPに戻る

RIZAPの生成AIへの顧客情報誤アップロードから考える ―企業が見直すべきシャドーAI対策

Share
RIZAPの生成AIへの顧客情報誤アップロードアイキャッチ画像

生成AIの業務利用が広がる一方、会社が把握・承認していないAIサービスを従業員が利用する「シャドーAI」は、情報漏洩につながるリスクの一つです。本記事では、RIZAPが公表した事案をもとに、生成AIへ情報を送信する際の注意点と、企業が見直すべきシャドーAI対策について解説します。

※本記事は2026年9月14日時点で公表されている情報に基づき作成しています。

RIZAPの生成AIへの誤送信で何が起きたのか

2026年9月3日、RIZAPは、社員が私用の外部生成AIサービスに顧客情報を誤ってアップロードしたと公表しました。[1]今回の事案は、RIZAPの社員が特定保健指導管理システムのデータを集計する際、顧客情報を外部の生成AIサービスに誤ってアップロードしたものです。対象は、同システムに2026年1月1日から8月19日までに登録された対象者データの一部で、氏名や保険証記号番号のほか、疾患情報などの要配慮個人情報も含まれます。同社の発表では、対象者数および利用された生成AIサービスの名称は公表されていません。またAI事業者以外の第三者による閲覧と学習利用の可能性はないと説明する一方、事業者の役職員等が閲覧可能だったかは確認中としています。外部生成AIへの情報送信では、閲覧の可能性と学習への利用は別の論点です。

図1:RIZAPの公表内容
※「学習されない」という説明だけで、外部送信の適否は判断できません。

出典:RIZAP株式会社「当社における外部生成AIサービスへのお客様情報の誤ったアップロードに関するお詫びとお知らせ」(2026年9月3日)(https://business.rizap.jp/news/2492)を基に作成

「学習されない」だけで生成AIへの入力を判断しない

外部の生成AIサービスにファイルをアップロードすると、まず、そのサービスへ情報を送信することになります。その後にどのように保存・処理され、誰がアクセスでき、学習に利用されるかは、契約や設定、サービスの仕様によって確認する論点です。一つの設定を見ただけで、情報の取り扱い全体を判断することはできません。

個人情報保護委員会は、生成AIに個人情報を含むプロンプトを入力する際、特定した利用目的の達成に必要な範囲かを確認するよう注意喚起しています。また、本人の同意なく入力した個人データが応答の出力以外の目的で扱われる場合には、法に違反する可能性があるとして、機械学習に利用しないこと等の十分な確認を求めています。[2]企業が確認すべきなのは、「学習をオフにしたか」に加えて、「この業務に、この情報を外部へ送る必要があるか」です。たとえば、集計式を知りたいだけなら実在する顧客のデータを渡さず、架空のサンプルで処理方法を相談できる場合があります。また、実データの処理が必要な場合は事前に承認された環境と手順で取り扱う業務プロセスを設計します。

シャドーAIとは? 私用アカウントと業務利用の境界

本記事で述べている「シャドーAI」とは、会社が把握・承認していないAIサービスを、従業員が業務に利用することです。たとえば、会社が承認していない個人アカウントで、会社の資料を要約したり、業務ファイルを分析したりする利用が該当します。同じサービス名でも、会社が契約・管理する環境と、従業員の私用アカウントでは、管理できる範囲や適用される条件が同じとは限りません。そのため、社内ガイドラインに「生成AIの利用可」とだけ記載しても、判断基準としては不足します。対象のサービスと契約プラン、使用するアカウント、許可する業務、入力できる情報を一緒に示す必要があります。「会社で使えるAI」と「自分が普段使っているAI」を現場が取り違えないよう、利用ルールや利用環境を整えることが大切です。

RIZAPでは再発防止策として、社内で許諾されていない生成AIの業務利用禁止の再周知、教育、アクセス権限や利用環境の点検・見直しを挙げています。企業が生成AIの利用を見直す際は利用ルールだけでなく、アクセス制限などの利用環境もあわせて確認する必要があります。

生成AIの情報漏洩を防ぐために企業が見直すべきこと

社内ルールは、現場の作業に沿った形で示すと使いやすくなります。以下は、企業が自社の契約や情報分類に合わせて具体化するための判断例です。

図2:生成AIへファイルを送る前の判断例

参考:個人情報保護委員会【別添1】「生成AIサービスの利用に関する注意喚起等について」(令和5年6月2日)(https://www.ppc.go.jp/files/pdf/230602_kouhou_houdou.pdf)等を参考に弊社作成。
※図は企業向けの一般的な判断例であり、法令上の適否を判定するものではありません。また、RIZAP社内の実際の運用を示すものではありません。

ファイル単位ではなく、中に含まれる情報まで確認する

表計算ファイルには、集計対象の列だけでなく、別のシートや自由記述欄に情報が残っている場合があります。そこで、アップロード用のデータを別に作成し、必要な項目だけを含める手順を設けます。氏名を削除しただけで安全と判断せず、番号や属性の組合せなど、個人を識別できる情報が残っていないかも確認します。

禁止事項と、迷ったときの相談先をセットにする

教育では「個人情報を入力しない」という説明に加え、集計表、議事録、顧客から届いた資料など、実際の業務を題材に判断を練習します。許可された使い方と相談窓口も示し、判断できないファイルは送信を止めて確認する運用にします。アクセス制限やデータ送信の制御を導入する場合も、対象のサービスや通信経路でどこまで制御できるかを確認したうえで、ルールを補完する仕組みとして位置付けます。

生成AIへ誤って情報を送信した場合の対応

生成AIへの誤送信に気付いたら、追加の送信を止め、社内の情報セキュリティ・個人情報管理の担当窓口へ速やかに報告します。サービス名、アカウント、送信日時、ファイルの内容、実施した操作を整理し、削除依頼や事業者への照会を進めます。必要な記録の保全と拡散防止は担当者の指揮で行い、記録用に機微な情報を別の外部サービスへコピーしないようにします。 確認したいのは、保存先と保持期間、閲覧の可能性、学習等への利用、削除の対象と完了状況です。画面上の履歴削除と、事業者側にあるデータの削除がどのような関係にあるかも確認します。行政機関への報告や本人への通知については、把握した事実に基づき、個人情報保護委員会の案内に沿って要否を判断します。[3]

生成AIの安全な業務利用に向けたBBSecの支援

生成AIの利用を始めていても、承認手順や教育が追い付いていない企業は、まずルールと実際の使い方の差を整理することが出発点になります。BBSecの「AIサービス提供者・利用者向けサイバーセキュリティ対策支援」では、AI利用者向けのセキュリティガイドライン雛形の提供と、事業に合わせたカスタマイズによる整備支援を用意しています。さらに、AI利用時の脅威・リスク・適切な利用方法・対策を扱う教育コンテンツの提供や、講師によるオンライン研修にも対応しています。既存の社内規程との整合性を見直したい場合は、「情報セキュリティ文書整備支援」により、文書体系の提案や既存文書の統廃合・改訂について支援を受けることもできます。生成AIを安全に業務利用するためには、ルールを定めるだけでなく、従業員が実際の業務で判断できるよう、教育とあわせて運用していくことが重要です。自社のAI利用ルールや教育体制を見直したい場合は、BBSecにご相談ください。

よくある疑問

▼ 個人情報を削除すれば、自由に使えますか?

【参考情報】

編集責任:木下


生成AIの安全な業務利用についてご相談ください

生成AIの安全な業務利用や、AI利用ルール・教育体制の整備についてお悩みの方は、ブロードバンドセキュリティ(BBSec)までお気軽にご相談ください。


ウェビナー開催のお知らせ

最新情報はこちら


Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像

Security NEWS TOPに戻る
バックナンバー TOPに戻る

OpenAIのAIエージェントが外部Wikiへ書き込み ―企業が見直すべき権限・通信・監視

Share
OpenAIのAIエージェントが外部Wikiへ書き込みアイキャッチ画像

情報取得のためにインターネットへのアクセスを許可されたAIエージェントが、想定されていなかった外部サイトへの書き込みにもその通信経路を利用していた――。OpenAIのAIエージェントによる外部Wikiへの書き込み事案は、AIエージェントにどこまで権限を与えるべきかを考える材料となりました。本記事では、この事案をもとに、企業がAIエージェントを利用する際に確認しておきたい権限・通信・承認・監視のポイントを解説します。

※本記事は2026年9月7日時点で確認できる公表資料に基づき作成しています。

OpenAIのWiki事案とは? 研究報告が示した行動

研究者は、外部Wikiに残された約1万8,000件のAIエージェントによる投稿を発見したと報告しています*7。活動の中心はドイツ語のDSEwikiでした。これはエージェントの台数や被害者数ではなく、投稿の数です。同報告では、エージェントがWeb検索課題の回答を共有し、動作環境の情報や制限を回避する方法も交換していたと説明されています。

図1:外部Wikiがエージェント同士の情報共有場所になる構図

主な活動:2026年5~6月(一部7月)/研究報告の公表:9月4日

出典:collusion.wiki「Discovery of a new OpenAI agent message board」(https://collusion.wiki/)を基に弊社作成
※約1万8,000件は、研究者が確認したAIエージェントによる投稿数であり、エージェント数ではありません。図中のエージェントは構図を説明するためのイメージです。

外部Wikiへの活動は5月に始まり、6月に急増しました。6月22日以降はほぼ停止し、7月1~2日に一部の活動が確認されています。研究報告が公表されたのは9月4日です。

「閲覧用の通信」と「書き込みできない状態」は同じか

技術面で注目したいのは、研究報告がGETリクエストを通じた外部Wikiへの書き込みを説明している点です*2。GETは、通常、Webページなどの情報を取得するために使われるHTTPのメソッドです。HTTPの仕様では安全なメソッドとして扱われ、クライアントがサーバーの状態変更を求めないことが基本の意味になります。

ただし、HTTPメソッドの仕様と、実際のWebアプリケーションの実装は必ずしも一致しません。研究報告によれば、今回利用された古いWikiでは、GETリクエストによって編集処理を実行できる仕組みが存在していました。そのため、エージェント側で通信をGETに限定していても、結果として外部サイトの状態を変更できました。この事案が示すのは、通信の名前だけで権限の境界を判断できないという問題です。

AIへの注意書きに加え、実行側で権限を制限する

AIに「外部には書き込まないでください」と指示することは、行動方針を伝える手段です。一方で、システムが実際にその操作を拒否できるかどうかは別に検証します。閲覧用途なら、閲覧に不要なツールや認証情報を与えず、アクセス先と実行可能な操作を絞る必要があります。

OWASPは、LLMを使うシステムに必要以上の機能・権限・自律性を与えるリスクを「LLM06:2025 Excessive Agency」として整理しています。利用目的に必要な機能だけを提供し、接続先のシステムでも権限を確認するという考え方は、AIエージェントの設計に役立ちます。

Hugging Face事案やプロンプトインジェクションとの違い

研究者は、Wikiで活動した群とHugging Faceへの攻撃に関わった群について、別のエージェント群だった可能性が高いと分析しています。そのため、両者は別の事案として捉える必要があります。また、Webページや文書に紛れた指示でAIの動作を変えようとする「LLM01:2025 Prompt Injection」と、エージェントが与えられた課題の達成に向けて想定外の手段を使う問題も同一ではありません。Wiki事案を特定のプロンプトインジェクション攻撃が原因だったと決め付けず、実際にどの操作が可能だったかに注目することが大切です。

AIエージェントのセキュリティ対策を、操作の流れで考える

企業がAIエージェントを導入する際には、モデル単体ではなく、ツール、認証情報、接続先を含む実行環境を確認します。以下は、OWASPの対策を基にした企業向けの設計例です。

図2:AIが提案した操作を、実行前後の制御で管理する

出典:OWASP「LLM06:2025 Excessive Agency」(https://genai.owasp.org/llmrisk/llm062025-excessive-agency/)および「AI Agent Security Cheat Sheet」(https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html)を基に弊社作成
※制御設計の例。実際の構成・承認条件・取得可能なログは、システムごとに定義します。OpenAIの実際の内部構成や、BBSecの個別サービス構成を表すものではありません。

最小権限と人の承認を、業務の影響に合わせて設定する

社内資料の検索を行うエージェントなら、必要な資料を読む権限に絞り、不要な更新・削除権限を持たせないようにします。外部送信、公開、重要データの変更など影響の大きい操作は、人が送信先と内容を確認してから実行する設計が考えられます。承認する操作と実行する操作が一致することも、実装時に確認します。

許可した接続先でも、使える操作を点検する

接続先の許可リストは管理の出発点になりますが、そのサイトやAPIで何ができるかまで点検します。検索・閲覧に必要な通信と、投稿・更新など状態を変える通信を区別し、目的外の操作を実行側で拒否できる構成を検討します。例外を追加したときは、許可範囲が広がっていないかを再確認します。

ログは「AIの回答」だけでなく「実際の操作」を残す

AIエージェントの挙動を調べるには、回答文だけでなく、呼び出したツール、接続先、実行結果、承認の記録を追えるようにします。誰の依頼で動いたエージェントか、どの権限を使ったかも結び付けておくと、想定外の操作が起きた際の調査に役立ちます。OWASPもエージェントのツール利用等の記録と異常の監視を推奨しています*3。

一方で、ログに個人情報や認証情報を無制限に残してよいわけではありません。調査に必要な記録と機微情報の保護を両立させ、閲覧権限と保存期間を定めます。異常な連続アクセスや承認外の操作を検知した後、誰がエージェントを止め、認証情報を無効化するのかまで運用手順に含めます。

BBSecの支援で、AIの利用方針とシステム設計をつなぐ

エージェントに任せる業務と、人が判断する業務の境界は、情報システム部門だけでなく利用部門も共有する必要があります。BBSecの「AIサービス提供者・利用者向けサイバーセキュリティ対策支援」は、提供者と利用者それぞれに向けたセキュリティガイドラインの雛形提供と、事業に合わせたカスタマイズによる整備支援を用意しています。

自社でAIエージェントを組み込むシステムを開発する場合には、BBSecの「Shift Left コンサルティング」も相談先になります。同サービスは、要件定義・設計段階でのセキュリティレビューや、システム・運用要件の評価と対策案の提示、開発標準・ガイドラインの策定支援を提供しています。まず、AIに許可する操作、接続先、承認が必要な処理を整理し、レビューしたい範囲を相談する進め方が考えられます。一般的なシステムのセキュリティレビューと、モデルの自律的な挙動を専門的に評価する試験は区別し、必要な評価内容を事前にすり合わせることが大切です。

AIエージェントの活用範囲は、止められる範囲から広げる

Wiki事案から企業が学べるのは、指示した内容に加え、システムとして何を許しているかを確認する姿勢です。扱う情報と操作を絞って検証し、記録・承認・停止の仕組みを整えたうえで活用範囲を広げる。権限の境界を具体的に設計することが、AIエージェントを業務で使い続けるための基盤になります。

【参考情報】

編集責任:木下


AIエージェントのセキュリティ対策をご検討の方へ

AIエージェントの導入・活用におけるセキュリティ対策についてお悩みの方は、ブロードバンドセキュリティ(BBSec)までお気軽にご相談ください。


ウェビナー開催のお知らせ

最新情報はこちら


Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像

Security NEWS TOPに戻る
バックナンバー TOPに戻る

SonicWall SMA1000の脆弱性が攻撃に悪用 ―CVE-2026-83548・CVE-2026-83549の影響と対策

Share
SonicWall SMA1000の脆弱性とは?CVE-2026-83548・83549の影響と対策アイキャッチ画像

2026年9月、SonicWallはリモートアクセス製品「SMA 1000シリーズ」に影響する複数の脆弱性を公表しました。これらの脆弱性は実際の攻撃での悪用が確認されており、米国CISAが公開する「Known Exploited Vulnerabilities(KEV)カタログ」にも追加されています。SMA 1000シリーズを利用している組織では、対象バージョンを確認し、速やかに対策を行う必要があります。本記事では、今回公表された脆弱性の概要や影響を受ける製品・バージョン、企業が実施すべき対応について解説します。

※本記事は2026年9月4日時点で確認できる公表資料に基づき作成しています。

SonicWall SMA1000とは

SonicWall Secure Mobile Access(SMA)1000シリーズは、社外の利用者から社内やクラウド上の業務システムへのアクセスを提供するセキュアリモートアクセス製品です。SMA 6210、SMA 7210の物理アプライアンスに加え、仮想アプライアンスのSMA 8200vが提供されています。リモートアクセス装置は、外部から内部資源へ接続するための入口という性質を持ちます。そのため、脆弱性が悪用された場合、単体の機器障害にとどまらず、認証情報や内部システムへのアクセスを含めた侵害可能性の調査が必要になります。今回、SonicWallがアップデートだけでなく侵害指標(IoC)の確認も求めているのは、このような製品の役割を踏まえた対応といえます。

CVE-2026-83548・CVE-2026-83549の概要

SonicWallが公表したのは、Appliance Work Placeインターフェースに存在する認証前のSSRFと、Appliance Management Console(AMC)に存在する認証後のOSコマンドインジェクションです。いずれも実際の攻撃での悪用が確認されていますが、攻撃者、被害組織、侵害台数、攻撃目的などの詳細は公表されていません。

CVE-2026-83548:認証前に悪用可能なSSRF(CVSS 10.0)

CVE-2026-83548は、SMA1000のAppliance Work Placeインターフェースに存在するサーバーサイドリクエストフォージェリ(SSRF)の脆弱性です。意図しない代替アクセス経路が生じることが原因とされ、リモートの未認証攻撃者が機密性の高い機能へ不正にアクセスし、許可されていない操作を行える可能性があります。深刻度はCVSS 10.0の「Critical」です。

SSRFとは、攻撃者が対象サーバーを代理にして、本来は外部から直接アクセスできない宛先へリクエストを送らせる攻撃です。公開インターフェースと内部の管理機能との境界を越える足掛かりになり得るため、認証前に悪用できる今回の脆弱性は特に優先度が高いと判断できます。

CVE-2026-83549:管理コンソールのOSコマンドインジェクション(CVSS 7.8)

CVE-2026-83549は、SMA1000のAppliance Management Console(AMC)に存在するOSコマンドインジェクションの脆弱性です。SonicWallによると、特定の条件下で、管理者として認証された攻撃者が任意のOSコマンドを実行し、リモートコード実行につながる可能性があります。深刻度はCVSS 7.8の「High」です。

2件はいずれも同じSMA1000に存在する脆弱性であることから、組み合わせて悪用される可能性にも注意が必要です。ただし、SonicWallの公開情報では、2件が実際に一つの攻撃チェーンとして利用されたことや、CVE-2026-83548を起点として認証なしでリモートコード実行に至ることまでは明らかにされていません。

影響を受ける製品と修正版

影響を受けるのはSMA 1000シリーズのSMA 6210、SMA 7210、SMA 8200vです。物理アプライアンスと仮想アプライアンスの双方が対象になります。SonicWall製ファイアウォール全般やSMA 100シリーズまで対象が広がるとの発表ではありません。自社の製品名だけでなく、platform-hotfixを含む完全なバージョン番号を確認してください。

対象製品影響を受けるバージョン修正版
SMA 6210/7210/8200v12.4.3-0345312.4.3-03526以上
SMA 6210/7210/8200v12.5.0-0283512.5.0-02952以上
出典:SonicWall「Product Notice: SMA 1000 Series affected by Multiple Vulnerabilities(SNWLID-2026-0016)」(https://www.sonicwall.com/support/notices/product-notice-sma-1000-series-affected-by-multiple-vulnerabilities-snwlid-2026-0016/kA1VN000002AXmQ0AW)を元に弊社作成

CVE情報では、12.4.3-03453および12.5.0-02835と、それ以前のバージョンが影響対象とされています。修正版は12.4系が12.4.3-03526、12.5系が12.5.0-02952です。SonicWallはMySonicWallから入手できる最新hotfixへのアップグレードを求めています。

CISAも既知の悪用された脆弱性カタログへ追加

2026年9月2日、米国サイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)は、CVE-2026-83548とCVE-2026-83549をKnown Exploited Vulnerabilities Catalog(KEVカタログ)へ追加しました。KEVへの掲載は、単に深刻度が高いというだけでなく、現実の攻撃で悪用された根拠があることを示します。 CISAは米国の連邦文民行政機関に対し、両脆弱性の対応期限を9月5日に設定しました。この期限が日本企業に直接適用されるわけではありませんが、公開からわずか数日という短い期限は、CISAが迅速な対応を必要と判断したことを表しています。SMA1000を利用する日本企業も、通常の定例アップデートを待つのではなく、緊急対応として扱うべき状況です。また、CISAのKEV情報ではフォレンジックトリアージも求められており、単なる修正プログラムの適用だけでなく、侵害の有無を確認することが重視されています。

なぜ『パッチを当てて終了』では不十分なのか

今回の脆弱性は、公表時点ですでに攻撃での悪用が確認されています。修正版へ更新すれば、その後に同じ脆弱性を利用されるリスクは抑えられますが、更新前に侵害されていなかったことまでは証明できません。攻撃者がすでに設定を変更したり、認証情報を取得したり、別の侵入経路を残したりしていれば、脆弱性を修正した後も影響が続く可能性があります。これは今回の被害状況を示すものではなく、侵害済み機器に対する一般的なリスクです。

SonicWallは、対象バージョンを利用するすべての組織に対し、最新hotfixへの更新に加えて、SonicWall Technical Supportへ連絡し、侵害指標を確認するよう案内しています。今回の公開アドバイザリには具体的なIPアドレス、ファイルハッシュ、URLパスなどのIoC一覧は掲載されていません。2026年7月に公表された別の脆弱性用IoCを、今回の調査へそのまま流用するべきではありません。

SMA1000利用組織が直ちに実施すべき対応

対象機器とhotfixレベルを確認する

まず、SMA 6210、7210、8200vの導入有無と、各機器の完全なバージョン番号を確認します。台帳だけに頼らず、運用委託先、クラウド環境、検証環境、待機系を含めて実機の状態と照合することが重要です。仮想アプライアンスも対象であるため、物理機器だけを確認して終えてはいけません。

最新hotfixへ更新する

12.4系は12.4.3-03526、12.5系は12.5.0-02952以上へ更新します。SonicWallは別の公式回避策を示していないため、アクセス制限などの補完策だけで更新を先送りすることは適切ではありません。業務影響を確認しながらも、悪用確認済みの脆弱性として優先的にメンテナンス時間を確保する必要があります。

侵害指標を確認し、影響範囲を調査する

更新と並行して、SonicWall Technical Supportの支援を受け、対象機器に侵害の痕跡がないかを確認します。必要に応じてログや設定を保全し、異常な管理操作、設定変更、認証の試行、外部との通信などについて確認します。ログが不足している場合は、周辺のファイアウォール、認証基盤、SIEMなどに残る記録も組み合わせて判断します。

IoCが確認された場合は機器と認証情報を再構成する

SonicWallはIoCが確認された場合、ハードウェアアプライアンスを再イメージ化し、仮想アプライアンスを再デプロイするよう求めています。加えて、すべての利用者および管理者パスワードを変更し、TOTPトークンをリセットする必要があります。TOTPリセットの推奨は、今回TOTPシードの窃取が確認されたことを意味するものではなく、侵害後に信頼できる認証状態を再構築するための措置と捉えるべきです。

7月の脆弱性対応後も、再度hotfixの確認が必要

SMA1000では2026年7月にも、SSRFのCVE-2026-15409と、リモートコード実行につながるCVE-2026-15410が公表され、実際の攻撃での悪用が確認されました。このときの修正版は12.4.3-03453および12.5.0-02835以上でした。今回の新たな脆弱性では、そのバージョンも影響対象となり、さらに新しい12.4.3-03526、12.5.0-02952への更新が必要です。

つまり、7月に緊急対応を完了した組織であっても、9月時点で再確認が欠かせません。製品名やメジャーバージョンだけで資産を管理するのではなく、hotfixレベルと適用日、脆弱性ごとの対応状況まで追跡できる運用が必要です。相次ぐ公表は、境界機器の脆弱性管理を年に数回の棚卸しで済ませることが難しい現実を示しています。

境界機器の脆弱性悪用に備える4つのポイント

外部公開資産を攻撃者と同じ視点で把握する

リモートアクセス装置、VPN、ファイアウォールなどの境界機器は、インターネットから到達できるため攻撃者に探索されやすい資産です。管理台帳と実際の公開状況が一致しているかを継続的に確認し、不要な機器や管理画面を公開しないことが基本になります。

悪用状況を加味して脆弱性対応の優先順位を決める

CVSSは重要な判断材料ですが、点数だけで対応順を決めると、現実の攻撃状況を見落とします。今回のCVE-2026-83549はCVSS 7.8である一方、悪用が確認され、CISA KEVにも掲載されています。製品の公開範囲、内部ネットワークへの接続性、KEV掲載、ベンダーの注意喚起を組み合わせ、緊急対応へ切り替える基準を定めておく必要があります。

ログを一元化し、調査できる期間を確保する

インシデント発生後に調査しようとしても、機器のログが短期間で上書きされていれば侵害の有無を判断できません。境界機器、認証基盤、ネットワーク、エンドポイントのログを一元的に保管し、時刻同期、保存期間、改ざん防止、監視ルールを平時から整えておくことが重要です。

再構築と認証情報のリセットを含む対応手順を用意する

境界機器が侵害された場合は、サービス停止や再構築が必要になることがあります。機器の再イメージ化、設定の安全性確認、パスワード変更、MFAトークンの再登録、代替のリモートアクセス手段まで含めた手順を準備し、事業継続部門と合意しておく必要があります。

BBSecが支援する外部公開資産の把握・監視・緊急対応

悪用確認済みの脆弱性へ迅速に対応するには、対象機器を把握する仕組み、脆弱性情報を運用へ反映する体制、侵害を検知・調査できるログ、緊急時に専門家へつなぐ手順を一つの流れとして整えることが重要です。BBSecでは、攻撃者の視点からインターネット上のIT資産を可視化する「アタックサーフェス調査」、脆弱性情報を迅速に提供する「脆弱性情報提供」、各種ログの分析・活用を支援するサービス、インシデント発生時の「緊急対応支援」などを提供しています。SonicWall SMA1000に限らず、VPNやリモートアクセス装置を含む境界機器の管理に不安がある場合は、外部公開資産の把握から監視、初動対応までを分断せずに見直すことが有効です。

セキュリティ対策について相談する

SonicWall SMA1000の脆弱性に関するFAQ

▼ SonicWall SMA1000のどの製品が影響を受けますか?
▼ CVE-2026-83548とCVE-2026-83549は実際に悪用されていますか?
▼ hotfixを適用すれば対応は完了しますか?
▼ 今回の脆弱性はゼロデイですか?

まとめ

SonicWall SMA1000のCVE-2026-83548とCVE-2026-83549は、実際の攻撃で悪用が確認され、CISA KEVにも追加された脆弱性です。SMA 6210、7210、8200vを利用する組織は、12.4.3-03526または12.5.0-02952以上への更新を急ぐ必要があります。対応の要点は、パッチを適用するだけで終わらせないことです。対象資産の特定、侵害指標の確認、必要に応じた再イメージ化または再デプロイ、パスワードとTOTPトークンのリセットまでを一連のインシデント対応として実施してください。境界機器は社内システムへ通じる入口です。脆弱性が公表されてから探し始めるのではなく、平時から資産、バージョン、ログ、対応責任者を把握しておくことが、ゼロデイ攻撃への備えになります。

【参考情報】

編集責任:木下


ウェビナー開催のお知らせ

最新情報はこちら


Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像

Security NEWS TOPに戻る
バックナンバー TOPに戻る

イエローハットに不正アクセス、最大約180万人分の個人情報漏えいの可能性―企業が学ぶべき対策とは

Share
イエローハットに不正アクセス、最大約180万人の個人情報漏えいの可能性アイキャッチ画像

2026年8月、カー用品大手のイエローハットが運営する「イエローハットWEB作業予約システム」が不正アクセスを受け、最大約180万人分の個人情報が漏えいした可能性があることが公表されました。本記事では、イエローハットの公式発表をもとに事案の概要を整理するとともに、企業が同様の被害に備えるために見直しておきたいセキュリティ対策について解説します。

※本記事は2026年9月4日時点で確認できる公表資料に基づき作成しています。

イエローハットの不正アクセスで何が起きたのか

株式会社イエローハットは2026年8月28日、「イエローハットWEB作業予約システム」が不正プログラムによる攻撃を受け、一部会員の個人情報が外部へ漏えいした可能性が判明したと発表しました*4。漏えいの可能性がある対象者は最大1,801,499名で、対象情報は氏名、電話番号、メールアドレス、会員番号とされています。同社は8月18日朝に不正アクセスを検知し、直ちにシステムの外部接続を遮断するなどの緊急措置を実施しました。その後、影響範囲などの調査を進める過程で、一部の会員情報が外部へ漏えいした可能性があることが判明したとしています。

公表時点でシステム上の対策は完了しており、個人情報保護委員会への報告と警察への相談も行われました。一方、クレジットカード情報、パスワード、車両情報は当該システムで保持していないため、同社は、これらの情報の漏えいはないと説明しています。また、グループ他社は異なる独自の管理システムを利用しているため、他ブランド店舗の利用者への影響もないとしています。

現時点で原因や侵入経路は公表されていない

今回のイエローハットの不正アクセスについて、攻撃者、侵入経路、悪用された脆弱性、攻撃手法の詳細は、2026年8月28日の公式発表では明らかにされていません。「Webシステムの脆弱性が悪用された」「認証情報が突破された」「ランサムウェアによる攻撃だった」などと原因を推測することはできません。また、公表された1,801,499名は、個人情報の漏えいが確認された人数ではなく、漏えいした可能性がある対象者の最大人数です。同社は今後新たな事実が判明した場合には、ホームページで公表するとしています。

利用者が注意すべき二次被害

イエローハットは、対象となる会員に対し、電子メール、SMS、電話または書面で順次連絡するとしています。同時に、心当たりのないメールやSMSなどに注意し、メールの開封、不審なリンクへのアクセス、添付ファイルの開封を避けるよう呼びかけています。氏名や連絡先、会員番号を組み合わせると、実在する企業やサービスを装った連絡に説得力を持たせやすくなります。ただし、今回の情報が実際にフィッシング等へ悪用されたとの事実は公表されていません。利用者は不安をあおる連絡に反応せず、案内の真偽をイエローハットの公式サイトや公式窓口で確認することが重要です。

2りんかんの不正アクセスとは別事案

イエローハットグループでは、株式会社2りんかんイエローハットも2026年4月に会員専用サーバーへの不正アクセスを公表しています*2。6月19日の最終報では、アプリの仕組みであるAPIを悪用した不正アクセスにより、3,179,454名分の会員データが取得されたことが特定されました。

ただし、2りんかんの事案と今回のイエローハット本体の事案を同じ原因によるものとみなすことはできません。今回対象となった「WEB作業予約システム」はグループ他社とは異なる独自管理システムであり、攻撃者や原因の共通性も公表されていません。企業が注目すべきなのは、二つの事案を安易に結び付けることではなく、グループ内でインシデントが発生した際に、類似する公開システムや利用技術、委託先などに同様のリスクがないか横断的に点検することです。

Web予約システムがサイバー攻撃の対象になり得る理由

Web予約システムは、顧客がインターネットから利用できる利便性の高い窓口である一方、外部に常時公開されるシステムでもあります。予約受付だけでなく、会員情報との連携、通知、店舗側の管理機能など、複数のシステムや機能とつながっているケースもあります。また、氏名や電話番号、メールアドレスなどの個人情報を扱うことも多いため、不正アクセスを受けた場合には情報漏えいにつながる可能性があります。そのため、公開前のセキュリティ確認だけでなく、運用開始後も継続的にリスクを管理することが重要です。

企業が見直すべき5つのセキュリティ対策

公開しているIT資産を把握し、管理責任を明確にする

最初に必要なのは、自社とグループ会社がインターネット上に公開しているWebサイト、予約システム、API、クラウド環境などを洗い出すことです。古いキャンペーンサイトや管理部門が不明確なシステムが残っていれば、脆弱性情報の確認や修正が遅れる原因になります。資産ごとに管理責任者、使用技術、保守委託先、個人データの有無を整理し、不要な公開資産は閉鎖する必要があります。

WebアプリケーションとAPIを継続的に点検する

Webシステムは公開前に確認して終わりではありません。機能追加、設定変更、ミドルウェアやライブラリの更新によってリスクは変化します。IPAは、Webサイトの新規公開前や既存ページの変更時の確認に加え、構成するソフトウェアやCMSを把握し、最新状態を保つことを推奨しています。システムの重要度や変更頻度に応じて、定期的な脆弱性診断やセキュリティ点検を実施することが有効です。

ログを『保存するだけ』にせず、検知と調査に使える状態にする

不正アクセスを早期に捉え、発生後に原因や影響範囲を調べるには、アクセスログや認証ログなどが欠かせません。ただし、ログが分散したまま、確認する担当者やルールが決まっていなければ、異常の発見につながりません。監視対象、検知条件、通知先、保管期間、時刻同期、改ざん防止を定め、異常を検知した際に調査へ移れる運用を整備することが重要です。

保有する個人データを最小化し、アクセスを必要な範囲に絞る

攻撃を完全に防ぐことは困難ですが、侵害された場合の影響を抑えることはできます。予約や会員サービスに本当に必要なデータだけを取得し、保存期限を過ぎた情報を削除し、業務上必要な担当者だけがアクセスできるようにします。決済情報を外部の専用システムで扱うなど、重要な情報を分離する設計も被害範囲を限定するうえで有効です。なお、これは一般的な推奨策であり、今回の事案に過剰保有やアクセス制御の不備があったことを示すものではありません。

インシデント対応手順を整え、グループ横断で訓練する

不正アクセスを検知した直後は、遮断、証拠保全、影響範囲の特定、経営層への報告、外部専門家や関係機関との連携、顧客への説明を並行して進めなければなりません。平時から責任者と連絡網を決め、初動手順を文書化し、机上演習で判断の遅れや役割の抜けを確認しておくことが重要です。グループ企業で事案が発生した場合は、当該システムの復旧だけで終わらせず、他社・他サービスへ横展開して点検する仕組みも必要です。

公開システムのセキュリティ対策を見直すには

Web予約システムのセキュリティ対策では、脆弱性を見つけて修正する予防策、攻撃の兆候を早期に捉える監視、被害が疑われた際の初動対応を分断しないことが重要です。どれか一つを導入するだけでは、継続的に変化する公開システムのリスクには対応しきれません。

BBSecでは、公開システムの脆弱性診断から、セキュリティログの分析・監視、インシデント発生時の緊急対応・フォレンジック調査までと、「予防」・「検知」・「対応」の各段階を支援しています。自社やグループ会社の公開システムをどこから見直すべきか判断に迷う場合は、現在の対策状況を整理したうえで、各段階での不足部分を補うことが有効です。

まとめ

イエローハットの不正アクセスでは、WEB作業予約システムに保存されていた最大約180万人分の個人情報が漏えいした可能性が公表されました。現時点では侵入経路や具体的な攻撃手法は明らかにされていないため、今後の調査結果や追加発表を確認する必要があります。企業にとって重要なのは、こうした事案を一過性のニュースとして捉えるのではなく、自社の対策を見直す機会とすることです。公開IT資産の把握、WebアプリケーションやAPIの継続的な点検、ログ監視、個人データの適切な管理、インシデント対応体制の整備を一連の取り組みとして進めることが、被害の予防と早期収束につながります。

【参考情報】

編集責任:木下


BBSecの脆弱性診断・セキュリティ対策支援サービス

BBSec(ブロードバンドセキュリティ)では、WebアプリケーションやAPIの脆弱性診断をはじめ、セキュリティログの分析・監視、インシデント発生時の緊急対応・フォレンジック調査など、予防・検知・対応の各段階を支援しています。公開システムのセキュリティ対策や、情報漏えい・不正アクセスへの備えを見直したい場合は、お気軽にご相談ください。


ウェビナー開催のお知らせ

最新情報はこちら


Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像

Security NEWS TOPに戻る
バックナンバー TOPに戻る

生成AIのリスクとは?企業利用で注意すべき情報漏洩・著作権・誤情報と対策

Share
生成AIのリスクとは?企業利用で注意すべき情報漏洩・著作権・誤情報と対策アイキャッチ画像

生成AIは、文章作成や要約、翻訳、情報収集、プログラミング支援など、さまざまな業務で利用されるようになりました。業務を効率化できる一方で、機密情報の漏洩や誤情報、著作権など、新たなリスクへの対応も必要です。

さらに、生成AIを利用するのは企業や一般のユーザーだけではありません。攻撃者がフィッシングメールの作成や攻撃に必要な情報収集などに生成AIを悪用することも考えられます。生成AIにはどのようなリスクがあり、企業はどう向き合えばよいのでしょうか。本記事では、企業による利用とサイバー攻撃への悪用という両面から、生成AIのリスクと対策を考えます。

生成AIの利用リスクだけでなく、AI・LLMを取り巻く脅威や企業に求められる対策の全体像については、「AIセキュリティとは?生成AI時代に企業が知っておくべきリスクと対策」で詳しく紹介しています。

生成AIの普及で広がる企業のリスク

生成AIは、一部の技術者や専門家だけが利用するものではなくなりました。メールや資料の作成、文章の要約、翻訳、アイデア出し、プログラムコードの作成・確認など、日常的な業務のさまざまな場面で活用されています。利用できる場面が広がるほど、生成AIが扱う情報も重要になります。

例えば、「文章を考えてもらう」だけであれば、入力するのは簡単な指示だけかもしれません。しかし、実際の業務では、顧客から届いたメールを貼り付けて返信を作成したり、会議録や契約書をアップロードして要約したり、ソースコードを入力して問題点を確認したりすることも考えられます。こうした使い方は便利ですが、生成AIに渡す情報の中に機密情報や個人情報などが含まれていれば、新たな情報管理の問題が生じます。

また、注意が必要なのは入力する情報だけではありません。生成AIが出力した内容が正しいとは限らず、その情報をどのように利用するかについても利用者側の判断が必要です。生成AIが業務に深く入り込むほど、「何を入力するのか」「何が出力されたのか」「その結果を何に使うのか」を考える必要性も高まっているのです。

企業が生成AIを利用する際のリスクは、大きく「入力」と「出力」に分けて考えると整理しやすくなります。

場面主なリスク
AIへの入力機密情報・個人情報の漏洩、著作物・知的財産の取り扱い
AIからの出力誤情報・ハルシネーション、著作権等の問題、AIへの過度な信頼
組織での利用シャドーAI、利用状況を把握できないリスク
外部からの脅威攻撃者による生成AIの悪用

生成AIに何を入力するかだけを管理しても、出力された情報を無条件に信用してしまえば別の問題が生じます。また、社内ルールを整備していても、従業員が管理外の生成AIを利用していれば、企業としてリスクを把握できません。

さらに、自社が生成AIを利用するリスクだけでなく、攻撃者が生成AIを利用することでサイバー攻撃が効率化される可能性についても考えておく必要があります。

生成AIに機密情報を入力するとどうなる?

生成AIの企業利用で特に注意したいのが、機密情報や個人情報の取り扱いです。例えば、次のような使い方は業務効率化のために自然に行われる可能性があります。

  • 顧客から届いたメールを貼り付けて返信文を作成する
  • 会議録をアップロードして要点をまとめる
  • 契約書を読み込ませて内容を要約する
  • ソースコードを入力してエラーの原因を調べる
  • 社内資料を読み込ませて新しい資料を作成する

しかし、そこに顧客情報や個人情報、社外秘情報、未公開情報などが含まれていれば、企業が管理すべき情報を外部の生成AIサービスへ渡すことになります。

「生成AIに入力するとすべて学習される」は正しい?

生成AIへの情報入力について、「入力した情報はすべてAIの学習に使われる」と説明されることがあります。しかし、必ずしも一律にそうなるわけではありません。入力データが保存されるのか、モデルの学習やサービス改善に利用されるのかといった条件は、サービスや契約プラン、設定などによって異なります。そのため、「生成AIだから機密情報を入力してはいけない」という単純な判断だけではなく、自社が利用するサービスで入力データがどのように取り扱われるのかを確認することが重要です。

企業では、利用規約やプライバシーポリシー、データの保存・利用条件などを確認したうえで、業務利用を認めるサービスを選定する必要があります。また、入力してよい情報と禁止する情報を具体的に定め、従業員に周知することも重要です。「機密情報は禁止」とするだけでなく、顧客情報、個人情報、社外秘資料、認証情報など、自社の業務に即した例を示すと判断しやすくなります。

生成AIと著作権で注意すべきこと

生成AIと著作権の問題についても、「AIが作ったものを使ってよいか」という生成物だけに目を向けるのではなく、AIへ何を入力するかという点から考える必要があります。

他人の文章や画像を生成AIに入力してよいのか

生成AIを利用する際、Web上の文章や画像、顧客・取引先から提供された資料などを入力することがあります。しかし、こうした情報には著作権のほか、契約上の秘密保持義務や利用条件などが関係する場合があります。「インターネットで公開されている」「自社が保有している」という理由だけで、どのような使い方でも認められるとは限りません。業務で生成AIへ情報を入力する場合は、その情報をAIサービスへ提供して問題がないかという観点からも確認する必要があります。

AIが作った文章や画像なら自由に使えるのか

生成AIが作成した文章や画像、プログラムコードなどについても、無条件に自由に利用できるとは限りません。生成物が既存の著作物と類似していたり、第三者の権利に関係する内容を含んでいたりする可能性があります。また、利用する生成AIサービスによって生成物に関する利用条件が異なる場合もあります。

特に、Webサイトや広告、製品、顧客向け資料など外部に公開するコンテンツに生成AIを利用する場合には、人による確認を行い、用途に応じて権利関係についても確認することが重要です。生成AIの利便性が高まるほど、「AIが作ったから問題ない」と考えず、最終的にその生成物を利用する側が確認するという意識が必要になります。

生成AIは「もっともらしく間違える」

生成AIのもう一つの特徴が、必ずしも正しい情報を出力するとは限らないことです。生成AIは、事実とは異なる情報を、自然で説得力のある文章として生成する場合があります。このような現象は「ハルシネーション」と呼ばれます。

例えば、

  • 存在しない事例を紹介する
  • 誤った数値を示す
  • 実在しない書籍や論文、Webページを出典として挙げる
  • 古い情報を現在の情報として回答する
  • 質問の前提を誤って解釈したまま回答する

といったことが考えられます。

問題は「間違いが間違いらしく見えない」こと

生成AIの誤情報で注意したいのは、単にAIが間違えることだけではありません。回答が自然な文章で生成されるため、利用者が誤りに気づかず、「AIが回答したのだから正しいだろう」と信用してしまう可能性があります。例えば、存在しない制度や統計を社内資料に記載したり、誤った内容を顧客への回答に使用したりすれば、企業の信用にも影響しかねません。

そのため、生成AIを検索エンジンや一次情報そのもののように扱うことは避ける必要があります。重要な情報については、公的機関や企業の公式情報、原典などを確認します。また、顧客への回答や外部公開資料、法務・財務・セキュリティなど重要な判断に利用する場合には、人によるレビューを組み込むことが必要です。

生成AIは判断を代替するものではなく、情報整理や作業を支援するツールとして使うことが基本となります。

生成AIはサイバー攻撃にも使われる

ここまでは企業が生成AIを「使う側」のリスクを見てきました。しかし、生成AIを利用できるのは企業や一般ユーザーだけではありません。攻撃者にとっても、生成AIは情報収集や文章作成、プログラミングなどを支援するツールになり得ます。

フィッシングメール作成のハードルを下げる

フィッシング攻撃では、受信者をだまして偽サイトへ誘導したり、マルウェアを実行させたりするためのメールやメッセージが利用されます。

生成AIを使えば、自然な文章の作成や翻訳、文章の修正などを短時間で行うことができます。攻撃対象の業種や立場に合わせた文章を作成する作業にも利用できるため、攻撃者によるコンテンツ作成の負担を減らす可能性があります。

従来、不自然な日本語や文法上の誤りは不審なメールを見分ける手掛かりの一つでした。しかし、生成AIによって自然な文章を容易に作成できるようになれば、文章の不自然さだけでフィッシングを見抜くことはさらに難しくなります。

マルウェアや攻撃コードの作成にも悪用されるのか

主要な生成AIサービスでは、有害なコンテンツやサイバー攻撃への悪用を防ぐための安全対策が講じられています。それでも、生成AIがプログラムコードの作成や修正、技術情報の整理などに利用できる以上、攻撃者が攻撃準備や作業の一部を効率化するために利用する可能性はあります。ここで重要なのは、「生成AIが登場したことで、これまで存在しなかったサイバー攻撃が突然生まれた」と捉えることではありません。

生成AIでサイバー攻撃はどう変わるのか

生成AIがサイバー攻撃に与える大きな影響の一つは、既存の攻撃を「速く」「大量に」「巧妙に」実行するための支援に使われる可能性があることです。

例えば、攻撃対象に関する情報収集、フィッシングメールの文章作成、翻訳、プログラムコードの作成支援など、従来は攻撃者自身が時間をかけて行っていた作業の一部を効率化できます。これは防御する企業側にとっても重要な変化です。これまでと同じ種類の攻撃であっても、攻撃者が試行できる量や速度が増えれば、企業が直面する脅威も変化します。

生成AI時代のセキュリティを考える際には、「AIそのものからどう情報を守るか」だけでなく、AIを利用して効率化される既存のサイバー攻撃にどう備えるかという視点も必要です。

生成AI時代でも基本的なセキュリティ対策は重要

生成AIによってサイバー攻撃が効率化・巧妙化する可能性があるからといって、企業に求められるセキュリティ対策がすべて新しいものに変わるわけではありません。フィッシングやマルウェア、不正アクセスなど、生成AIが悪用される可能性のある攻撃の多くは、以前から存在する攻撃手法です。そのため、生成AI時代においても、基本的なセキュリティ対策を継続することが重要です。

基本的なセキュリティ対策の例

基本的な対策こそが重要の画像

特にフィッシングについては、生成AIによって自然な文章を作成しやすくなることで、「日本語が不自然だから怪しい」といった従来の見分け方だけでは判断が難しくなる可能性があります。送信元やURL、要求されている操作などを確認し、文章の自然さだけでメールの安全性を判断しないことが大切です。

生成AIによる脅威を特別なものとして切り離して考えるのではなく、従来のセキュリティ対策を着実に行ったうえで、生成AIの利用や悪用によって生じる新たなリスクへの対策を加えていくことが基本となります。

「生成AIは危険だから禁止」でよいのか

ここまで生成AIのさまざまなリスクを見てきました。それでは、企業は生成AIの利用を禁止すれば安全なのでしょうか。生成AIを利用しなければ回避できるリスクがあるのは確かです。しかし、利用禁止だけで問題が解決するとは限りません。

禁止だけでは「シャドーAI」につながる可能性も

組織が許可・把握していない生成AIサービスを従業員が業務に利用することは、「シャドーAI」と呼ばれます。例えば、会社では生成AIの利用を認めていなくても、従業員が個人アカウントで生成AIへアクセスし、業務資料を要約しているかもしれません。

この場合、企業側では、

  • 誰がどの生成AIを利用しているのか
  • どのような情報を入力したのか
  • 入力データがどのように扱われているのか
  • 生成された情報を何に利用したのか

を把握することが難しくなります。生成AIを禁止するか許可するかという二者択一ではなく、業務上の利用ニーズとリスクの両方を踏まえて管理することが重要です。

リスクを理解したうえで利用する

生成AIを安全に利用するためには、「生成AIは危険か、安全か」という単純な判断ではなく、利用方法を具体的に考える必要があります。

例えば、

  • どの生成AIサービスを利用するのか
  • どのような業務に利用するのか
  • 何を入力してよいのか
  • AIの出力を誰が確認するのか
  • 問題が起きた場合にどこへ報告するのか

といった点を明確にすることで、リスクを管理しながら生成AIを活用しやすくなります。

生成AIを安全に利用するために企業が行うべき5つの対策

生成AIのリスクは、特定のセキュリティ製品だけで解決できるものではありません。利用環境、ルール、教育などを組み合わせ、組織として取り組む必要があります。

  1. 利用する生成AIサービスを決める
    業務で利用を認める生成AIサービスを明確にします。サービスの機能だけでなく、入力データの保存・利用条件、アクセス管理、管理者向け機能なども確認して選定します。
  2. 入力してよい情報・禁止する情報を決める
    生成AIへ入力できる情報の範囲を明確にします。個人情報、顧客情報、社外秘資料、ソースコード、認証情報など、自社で実際に扱う情報を例示すると、従業員が判断しやすくなります。
  3. AIの出力を確認する
    生成AIから得た回答や生成物をそのまま利用せず、用途に応じて確認します。特に外部公開する情報、顧客への回答、重要な意思決定に利用する場合には、事実関係や権利関係などを人が確認するプロセスを設けます。
  4. AI利用ガイドラインを整備する
    利用可能なサービスや用途、入力禁止情報、生成物の確認方法、問題が発生した場合の報告先などをルールとして整理します。
  5. 利用状況を把握し、継続的に見直す
    生成AIのサービスや機能は変化し続けています。新しいサービスが利用されていないか、現在のルールが実態に合っているかを定期的に確認します。新たなリスクや利用方法が確認された場合には、ガイドラインや利用環境、従業員教育も見直していくことが重要です。

AI利用ガイドラインや組織としての管理体制については、「AIガバナンスとは?企業に必要な体制とAI利用ガイドラインの作り方」で詳しく紹介します。

生成AIのリスクに関するよくある質問

▼ ChatGPTなどに会社の情報を入力すると情報漏洩になりますか?
▼ 生成AIで作った文章や画像は自由に利用できますか?
▼ 会社で生成AIの利用を禁止すれば安全ですか?
▼ 生成AIによってサイバー攻撃は増えるのでしょうか?

まとめ

生成AIは、業務を効率化する便利なツールである一方、機密情報の漏洩、著作権・知的財産、誤情報など、利用方法に応じたリスクがあります。また、攻撃者が生成AIを利用し、フィッシングなど既存のサイバー攻撃を効率化する可能性にも注意が必要です。

重要なのは、生成AIを過度に恐れることではなく、どのような場面で、どのようなリスクが生じるのかを理解したうえで利用することです。企業では生成AIの利用を個々の従業員の判断だけに任せず、利用するサービス、入力できる情報、生成物の確認方法などを明確にする必要があります。さらに、利用状況を把握し、AIサービスや脅威の変化に応じてルールや対策を継続的に見直していくことが、安全な生成AI活用につながります。

公開日:2023年6月28日
更新日:2026年9月2日

編集責任:木下


BBSecでは

AIの利用拡大に伴い、企業を取り巻くIT環境やセキュリティリスクも変化しています。公開IT資産の把握、脆弱性の確認、セキュリティ対策の有効性検証など、自社の課題に応じた対策をご相談ください。


Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像

Security NEWS TOPに戻る
バックナンバー TOPに戻る

さくらのレンタルサーバ不正アクセスが示す「管理環境」のリスク―583アカウントに不正ログイン

Share
さくらのレンタルサーバで不正アクセスアイキャッチ画像

2026年8月17日、さくらインターネットは「さくらのレンタルサーバ」の一部顧客環境への不正アクセスを公表しました。本記事では、同社や公的機関の一次情報をもとに、判明している事実や情報漏えいの可能性、利用企業が確認すべき対策を解説します。

※本記事は2026年8月17日時点で確認できる公表資料に基づき作成しています。

さくらインターネットへの不正アクセスで何が起きたのか

さくらインターネットの発表によると、同社は2026年8月9日、管理するサーバ環境で異常を検知し、調査を開始しました*3。その後、第三者が同社の管理環境を経由して、「さくらのレンタルサーバ」の一部顧客環境へ不正アクセスしていたことが判明しました。8月9日は攻撃開始日ではなく、異常を検知した日です。

8月17日の公表時点で、不正ログインの対象は583アカウントです。第三者が顧客アカウントからアクセスできる領域まで到達していたほか、一部のサーバにはマルウェアが設置されていました。また、一部の顧客情報を含む個人データが、第三者に閲覧または取得された可能性があるとされています。漏えいした可能性がある情報として挙げられているのは、「顧客領域内に保存された情報」と「利用者識別子」です。ただし、具体的な情報項目、対象人数、実際に取得されたデータの範囲は調査中です。

同社は認証情報の失効、アクセス遮断、マルウェアの除去、監視強化、外部専門機関を交えたフォレンジック調査を進めています。あわせて、データベースアップグレード機能、プラン変更、移行ツールなどの一部機能を制限しています。現時点では「さくらのVPS」「さくらのクラウド」「さくらの専用サーバ PHY」「高火力 PHY」への影響は確認されていませんが、その他のサービスを含めた調査は継続中です。

注目すべきは『管理環境を経由』した点

一般的なWebサイトの不正アクセスでは、更新されていないCMSやプラグイン、弱いパスワードなど、顧客側の環境が侵入口になるケースがあります。しかし今回の発表は、第三者がさくらインターネットの管理環境を経由して顧客環境へアクセスしたと説明しています。「管理環境」が具体的にどのシステムを指すのか、最初の侵入に脆弱性や窃取された認証情報が使われたのかは公表されていません。そのため、特定の製品やWordPressの脆弱性、ゼロデイ攻撃などと結び付ける根拠はありません。それでも、サービス提供者側の管理環境を経由し、複数の顧客アカウントへ影響が及んだ点は重要です。

さくらインターネットのサポート情報によれば、「さくらのレンタルサーバ」は複数の利用者が1台のサーバを共有する共用サーバとして運営されています*2。共用ホスティングでは、利用企業が自社サイトを適切に管理していても、サービス提供者側の管理層で発生した問題の影響を完全にコントロールすることはできません。これは「レンタルサーバだから危険」という話ではありません。自社ですべてのサーバを運用する場合にも、別の脆弱性や運用リスクがあります。重要なのは、外部サービスへ運用を委ねることで負担は軽減できても、情報管理やインシデント対応まで外部へ丸投げできるわけではないという点です。なお、「さくらのレンタルサーバ」は共用サーバとして提供されていますが、今回の不正アクセスと共用サーバという構成との因果関係は公表されていません。

583アカウントは「583人分の情報漏えい」ではない

今回さくらインターネットから公表された「583」という数字は、情報漏えいが確認された人数ではなく、不正ログインが判明したアカウント数です。また、「被害申告が確認されていない」ことと「改ざんがなかったことが確認された」ことは区別して捉える必要があります。現段階では、不正ログインとマルウェアの設置は確認済みである一方、個々の顧客環境で何が閲覧、取得、変更されたのかを調べている途中だと捉えるのが適切でしょう。

「通信の秘密」に該当する情報とは

さくらインターネットは、攻撃者が顧客情報だけでなく、「通信の秘密」に該当する情報へアクセスできる状態にあったと説明しています。通信の秘密は、メール本文などの通信内容だけを意味するものではありません。

個人情報保護委員会と総務省の「電気通信事業における個人情報等の保護に関するガイドライン」では、通信当事者の住所や氏名、発受信場所、通信年月日、通信回数、通信の存在自体に関する情報も含まれるとされています。ただし、今回どの情報が実際に閲覧・取得されたのかは公表されておらず、具体的な影響範囲は調査中です。さくらインターネットは、総務省や個人情報保護委員会などの関係機関への報告・情報共有を行うとともに、影響の可能性がある顧客への個別通知を開始しています。

レンタルサーバの侵害が企業へ及ぼす影響

企業が利用するレンタルサーバには、WebサイトのHTMLファイルや画像だけが置かれているとは限りません。問い合わせフォームから取得した情報、会員データ、データベース、業務用メールなどが保存されている場合があります。アプリケーションの設定ファイルに、データベースや外部クラウドサービスへ接続するための認証情報が記録されているケースもあります。

さくらインターネットの公式マニュアルでは、サーバーコントロールパネルへ管理者権限でログインした場合、そのレンタルサーバで行えるすべての操作に加え、作成された全メールアドレスの受信メール閲覧や設定変更などが可能と説明されています*3。ただし、今回不正ログインされた583アカウントが、この管理者権限を持つアカウントに該当するかは公表されていません。ここで重要なのは、実際の被害を先回りして断定することではなく、自社がサーバ上に何を保存し、どのシステムと接続しているかを把握しておくことです。

Webサイトが停止・改ざんされれば、情報発信や問い合わせ受付、ECサイトの販売などに影響します。仮にメールアカウントなどが不正利用された場合には、なりすましメールやフィッシング、取引先への攻撃に悪用されるおそれもあります。外部サービス上の一つのアカウントが、社内外の複数システムをつなぐ接点になっていないかを確認する必要があります。

相次ぐサービス提供者側の不正アクセス

サービス提供者側のシステムが侵害され、利用企業やその顧客へ影響が波及した事例は、今回が初めてではありません。

2025年には、インターネットイニシアティブ(IIJ)の法人向けメールセキュリティサービス「IIJセキュアMXサービス」が、第三者製ソフトウェアの当時未発見だった脆弱性を悪用した不正アクセスを受けました。そして2026年には、KDDIがISP事業者向けに提供していたメールシステムでも、第三者製ソフトウェアの未知の脆弱性を悪用した不正アクセスが発生し、メールアドレスやパスワードなどの漏えいが確認されています。

IIJやKDDIの事案と、今回のさくらインターネットへの不正アクセスが同じ原因や攻撃手法によるものだと示す情報はありません。一方、サービス提供者のシステムが侵害された場合、その影響がサービスを利用する複数の組織へ広がり得る点は共通しています。

IPA「情報セキュリティ10大脅威 2026」でも、「サプライチェーンや委託先を狙った攻撃」は組織向け脅威の2位となっています。ただし、今回の侵入原因や攻撃者の目的は判明しておらず、本件をサプライチェーン攻撃と断定することはできません。「委託先やITサービスを通じて自社へ影響が及ぶリスク」を考えるための事例として捉えるのが適切です。

さくらのレンタルサーバ利用者が確認すべきこと

今回の事案を受けて確認すること

さくらインターネットは利用者に対し、身に覚えのないファイルや管理者アカウントが追加されていないか、Webサイトやアプリケーションに不審な変更がないか、心当たりのないログインやメール送信が発生していないかを確認するよう求めています。確認の際は、現在表示されているWebサイトだけを見て「異常なし」と判断するのではなく、サーバーコントロールパネルのログイン履歴、取得できる範囲の接続・メール送信ログ、ファイルの更新日時なども確認します。身に覚えのないファイルや不審な通信を発見した場合は、調査に必要な記録を残したうえで、さくらインターネットやセキュリティの専門家へ相談することが重要です。

なお、2026年8月17日時点では、全利用者に対する一律のパスワード変更は求められていません。さくらインターネットは、パスワード変更などの追加対応が必要と判明した場合、対象者へ個別に案内するとしています。個別通知を受けた場合はその指示に従い、同じパスワードを他のサービスでも使用している場合は、該当サービスのパスワードも変更する必要があります。

平時から備えておくこと

平時の対策としては、サーバーコントロールパネルとWebメールの二要素認証を有効にし、管理者権限を必要な担当者だけに限定することが有効です。ただし、今回のようにサービス提供者の管理環境を経由した不正アクセスでは、利用者側の二要素認証だけですべてのリスクを防げるとは限りません。今回の侵入を二要素認証で防げたとする情報も公表されていないため、一般的なアカウント乗っ取り対策として捉える必要があります。また、Webサイト、データベース、メール、設定ファイルなど、サーバ上に保存している情報を定期的に棚卸しし、漏えいした場合の影響を把握しておくことも重要です。あわせて、復旧に必要なデータは同じサービス内だけに保存せず、別の媒体や環境にもバックアップを保持します。

IPAの「日常における情報セキュリティ対策」では、データを3つ持ち、2種類の異なる媒体でバックアップし、そのうち1つは異なる場所(オフサイト)で保管する「321ルール」を紹介しています。

外部へ委託しても自社のリスク管理は必要

レンタルサーバやクラウドサービスを利用する目的の一つは、専門事業者へ運用を任せ、自社の負担を軽減することです。しかし、サービス上で扱う情報の種類や重要度を決めるのは利用企業であり、インシデント発生時には、利用企業側にも顧客や取引先への説明・対応が求められる場合があります。サービスを選ぶ際は、料金や容量、表示速度だけでなく、取得できるログ、バックアップの保存場所、障害・不正アクセス時の連絡方法、調査への協力範囲、データの返却・削除方法なども確認しておく必要があります。特に、Webサイトやメールが事業継続に直結する企業では、サービス停止や情報漏えいを想定した連絡体制と復旧手順を、委託先と共有しておくことが重要です。

IPAが進める「サプライチェーン強化に向けたセキュリティ対策評価制度」でも、ITサービスを含む委託先への攻撃を起点としたサービス停止、機密情報の漏えい、改ざん、踏み台化などがリスクとして挙げられています。委託先のセキュリティを確認することは、自社の事業を守るためのリスク管理です。

さくらのレンタルサーバ不正アクセスに関するFAQ

▼ 自分のアカウントが対象か確認する方法は?
▼ パスワード変更は必要ですか?
▼ どの情報が漏えいした可能性がありますか?

まとめ

今回のさくらインターネットへの不正アクセスでは、583アカウントへの不正ログインや一部サーバへのマルウェア設置が確認され、顧客領域に保存された情報などが第三者に閲覧・取得された可能性も公表されています。一方、侵入経路や攻撃の開始時期、実際に取得された情報の範囲などは、現時点では調査中です。今回注目すべきなのは、被害の数字だけでなく、サービス提供者の管理環境を経由して複数の顧客環境へ不正アクセスが行われた点です。利用企業は公式情報を継続的に確認するとともに、自社環境に不審な変更がないかを点検し、サーバ上に保存している情報や外部システムとの接続関係を把握しておく必要があります。 外部サービスを利用していても、自社の情報や事業へのリスクがなくなるわけではありません。本件を、自社のセキュリティ対策だけでなく、委託先やITサービスを含めたリスク管理を見直す機会とすることが重要です。

参考情報

編集責任:木下


BBSecの脆弱性診断・セキュリティ対策支援サービス

BBSec(ブロードバンドセキュリティ)では、Webアプリケーション診断、プラットフォーム診断、クラウド環境診断、脆弱性管理支援など、企業のセキュリティリスクを可視化する各種サービスを提供しています。外部サービスや委託先を含めたセキュリティ体制の見直し、情報漏えいリスクへの備え、インシデント発生前の予防対策を検討している企業は、ぜひご相談ください。


ウェビナー開催のお知らせ

  • 2026年8月26日(水)「AI時代に見直すセキュリティ対策 ~ASMの考え方で始める攻撃対象領域の可視化とリスク対策~」
  • 最新情報はこちら


    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    2026年2Q KEVカタログに見る攻撃トレンド ― 実際に悪用された脆弱性から読み解く攻撃者の狙い

    Share
    2026年2Q KEVカタログに見る攻撃トレンドアイキャッチ画像

    前回記事では、2026年第2四半期(2Q)のKEVカタログを統計データから分析しました。本記事では、同期間にKEVへ追加された脆弱性のうち、実際の攻撃事例に着目。攻撃者が狙う製品の共通点や脆弱性の悪用方法を分析し、2026年2Qに見られた攻撃トレンドを読み解きます。

    実際の攻撃事例から見える2026年2Qの特徴

    2026年第2QにKEVへ追加された脆弱性のうち、具体的な攻撃事例が確認されているものを見ると、VPNやRMM(Remote Monitoring and Management)、メールサーバ、業務システム、開発ツールなど、さまざまな製品が攻撃対象となっています。一見すると異なる製品ですが、事例を横断すると共通点も見えてきます。特に注目したいのが、インターネットからアクセス可能なシステムや、侵害後に組織内部へのアクセスに利用できる管理系製品が狙われていることです。

    攻撃者にとっては、こうした製品を侵害できれば、その先にある社内ネットワークへ侵入する足掛かりを得られます。つまり、狙われているのは単に「脆弱な製品」ではなく、侵害後の展開に利用価値の高い製品だと考えることができます。

    さらに、開発環境やソフトウェアサプライチェーンを起点として、別の製品や利用者へ被害が連鎖する事例も見られました。以下では、代表的な事例から、こうした攻撃の特徴を詳しく見ていきます。

    VPNや管理システムは「入口」として狙われる

    象徴的な事例の一つが、Check Point Security GatewayのCVE-2026-50751です。この脆弱性は、非推奨となっているIKEv1を利用したRemote Access VPNなどに存在する認証回避の脆弱性で、攻撃者が有効なユーザーパスワードを持たなくてもVPNセッションを確立できる可能性があります。Check Pointは実際の悪用を確認しており、事例の一つには侵害後の活動にランサムウェア「Qilin」との関連性も確認されています*4。

    VPNは本来、社外から安全に組織内部へ接続するための仕組みです。しかし、その認証機構自体が突破されれば、攻撃者にとっては社内ネットワークへの正規の入口に近い役割を果たしてしまいます。

    同様の特徴は、Oracle PeopleSoft Enterprise PeopleToolsのCVE-2026-35273にも見られます。Google Threat Intelligence GroupとMandiantは、ShinyHuntersとして知られるUNC6240による攻撃でこの脆弱性と整合する悪用を確認しています*2。活動はOracleによるアドバイザリ公開前から観測されており、ゼロデイとして悪用されていたと分析しています。

    狙われるRMM・リモート管理製品の脆弱性

    同様に注意したいのがRMM製品です。2026年第2Qには、ConnectWise ScreenConnectのCVE-2024-1708や、SimpleHelpの複数の脆弱性もKEVへ追加されています。

    SimpleHelpでは、CVE-2024-57726やCVE-2024-57728など、複数の脆弱性が確認されています。CVE-2024-57726では低権限の技術者アカウントから過剰な権限を持つAPIキーを作成して管理者権限へ昇格でき、CVE-2024-57728では管理者権限を得た攻撃者が細工したZIPファイルを利用して任意の場所へファイルを書き込み、コード実行につなげられる可能性があります。SimpleHelp自身も、これらの脆弱性を組み合わせることで、情報取得から権限昇格、最終的なコード実行までの攻撃チェーンが成立し得ると説明しています。

    RMM製品は、管理者が複数の端末へ遠隔接続し、操作やソフトウェア配布などを行うための正規ツールです。そのため、攻撃者に侵害された場合、単にRMMサーバ自体が被害を受けるだけではありません。正規の管理機能が、侵入後のアクセス維持や別端末への展開に悪用される可能性があります。

    これらの事例に共通するのは、侵害後に組織内部へアクセスしやすい製品が攻撃対象になっていることです。攻撃者にとって重要なのは、脆弱性そのものの深刻度だけではありません。その製品を侵害した後に「どこまでアクセスできるか」「次の攻撃へつなげられるか」という点も、標的を選ぶうえで重要な要素になっていると考えられます。Microsoftが報告したStorm-1175の活動でも、この特徴が明確に表れています。

    既知の脆弱性を使い分けるランサムウェア攻撃

    Storm-1175は、ランサムウェア「Medusa」を展開する金銭目的の攻撃者です。Microsoftによると、同グループはインターネット上に公開された脆弱なシステムを探索し、主に公開済みのNデイ脆弱性を悪用して初期侵入した、といいます*3。侵入後は情報窃取などを行い、数日以内、場合によっては24時間以内にランサムウェア展開まで進むことが確認されています。Storm-1175の特徴は、特定の製品や一つの脆弱性だけを狙っているわけではない点です。

    Nデイ脆弱性についてはこちらの記事でも解説しています。あわせてぜひご覧ください。
    「定期的な脆弱性診断でシステムを守ろう!-放置された脆弱性のリスクと対処方法-」

    Microsoftの調査では、PaperCut、Microsoft Exchange Server、ConnectWise ScreenConnect、JetBrains TeamCity、SimpleHelp、BeyondTrustなど、複数の製品の脆弱性が初期侵入に利用されていました。2026年第2四半期にKEVへ追加された脆弱性にも、これらの活動で利用されたものが複数含まれています。侵入後には、新しい管理者アカウントを作成してアクセスを維持し、PowerShellやPsExecなどのツールを使用してネットワーク内部へ展開します。さらに、RMMツールを永続化やペイロード配布、横展開などに利用し、認証情報の窃取やセキュリティ機能の妨害を経て、最終的にMedusaランサムウェアを展開するという攻撃の流れが確認されています。

    この事例から見えてくるのは、攻撃者が特定のCVEだけに固執するのではなく、外部から侵入可能な複数の脆弱性を使い分け、その時点で利用できるものを入口としているという実態です。つまり、一つの注目度の高い脆弱性だけに対応しても、別のインターネット公開システムに悪用可能な脆弱性が残っていれば、そこが新たな侵入口になる可能性があります。

    開発環境も攻撃対象に ― サプライチェーン経由の侵害

    もう一つ、2026年第2Qで注目したいのが、一般的なWebサーバやVPNへの脆弱性攻撃とは異なるソフトウェアサプライチェーン経由の攻撃です。CVE-2026-45321として登録されたTanStackのサプライチェーン侵害では、正規のnpmパッケージとして悪意あるバージョンが公開されました。悪意あるコードは、AWSやGCPなどのクラウド認証情報、GitHubトークン、npmトークン、SSH秘密鍵など、開発環境に保存されているさまざまな認証情報を窃取する機能を持っていました。さらに、この侵害は別の製品にも波及しました。

    Nx ConsoleのCVE-2026-48027では、悪意あるバージョンのVS Code拡張機能が公開され、ディスクやメモリ上の認証情報を収集するペイロードが実行されました。Nxの調査によると、開発者の一人がTanStackに関連するサプライチェーン攻撃の影響を受け、流出したGitHub認証情報がNx Consoleの不正公開につながったとされています*4。

    つまり、ある開発ツールの侵害 → 認証情報の窃取 → 別プロジェクトの侵害 → 正規ソフトウェアを通じた被害拡大、という連鎖が生じたことになります。

    Nx Consoleの悪意のあるバージョンは、Visual Studio Marketplaceでは約18分間公開されていました。短時間で削除されたとしても、ソフトウェアの自動更新や正規マーケットプレイスへの信頼を利用した攻撃では、その間に利用者へ影響が及ぶ可能性があります。 これは、境界機器の脆弱性を突いて社内へ侵入する攻撃とは異なります。正規の配布経路や信頼された開発者アカウントそのものが攻撃経路になるため、「正規のアップデートだから安全」という前提だけでは防ぎにくい点が特徴です。

    2026年2Qの事例から見えた3つの攻撃トレンド

    今回の事例を横断すると、三つの特徴が見えてきます。

    第一は、攻撃者が侵害後の展開に利用しやすいシステムを入口としていることです。VPNやRMMなどは外部からアクセス可能であるだけでなく、組織内部への接続や複数端末の管理といった機能を持っています。そのため、侵害されると、その正規機能自体が次の攻撃段階へ進むための足掛かりになり得ます。第二は、攻撃者が複数の既知脆弱性を使い分けていることです。Storm-1175の事例では、PaperCut、Microsoft Exchange Server、ConnectWise ScreenConnect、JetBrains TeamCity、SimpleHelp、BeyondTrustなど、複数製品のNデイ脆弱性が初期侵入に利用されていました。重要なのは、個々の脆弱性の新旧だけではなく、攻撃者が外部から侵入可能なシステムを探し、その時点で利用可能な脆弱性を入口としている点です。第三は、攻撃対象が組織の境界から開発環境やソフトウェアサプライチェーンへも広がっていることです。TanStackとNx Consoleの事例では、一つの認証情報の侵害が別のソフトウェアへ連鎖し、正規の配布経路を通じて被害が広がるリスクが示されました。

    これらに共通するのは、攻撃者にとっての「侵害後の価値」です。外部から到達できるか、高い権限や重要な認証情報を得られるか、さらに別のシステムへアクセスできるかといった条件が、攻撃対象を考えるうえで重要になっていると考えられます。

    まとめ

    2026年第2四半期にKEVへ追加された脆弱性の実際の悪用事例を見ると、統計データだけでは見えにくい攻撃者の行動が浮かび上がってきます。VPNやRMMなどの管理系システムを足掛かりとした侵入、既知の脆弱性を使い分けて短期間でランサムウェア展開まで進む攻撃、そして開発環境から別のソフトウェアへ被害が連鎖するサプライチェーン攻撃など、攻撃経路は多様化しています。こうした事例を見るうえで重要なのは、「どのCVEが危険なのか」だけでなく、その製品やシステムが侵害された場合、攻撃者が次に何をできるのかという視点です。実際の悪用事例と自組織のIT資産を照らし合わせ、インターネットへの公開状況や権限、他システムとの接続関係まで含めてリスクを捉えることが、攻撃の早期発見や被害拡大の防止につながります。

    【参考情報】

    編集責任:木下


    BBSecでは

    アタックサーフェス調査サービス

    インターネット上で「攻撃者にとって対象組織はどう見えているか」調査・報告するサービスです。攻撃者と同じ観点に立ち、企業ドメイン情報をはじめとする、公開情報(OSINT)を利用して攻撃可能なポイントの有無を、弊社セキュリティエンジニアが調査いたします。


    サイバーインシデント緊急対応

    セキュリティインシデントの再発防止や体制強化を確実に行うには、専門家の支援を受けることも有効です。BBSecでは緊急対応支援サービスをご提供しています。突然の大規模攻撃や情報漏洩の懸念等、緊急事態もしくはその可能性が発生した場合は、BBSecにご相談ください。セキュリティのスペシャリストが、御社システムの状況把握、防御、そして事後対策をトータルにサポートさせていただきます。

    サイバーセキュリティ緊急対応電話受付ボタン
    SQAT緊急対応バナー

    ウェビナー開催のお知らせ

  • 2026年8月19日(水)14:00~15:00「セキュリティ対策の有効性を検証する ―ペネトレーションテストの実施ポイントと脆弱性診断との違い―」
  • 2026年8月26日(水)「AI時代に見直すセキュリティ対策 ~ASMの考え方で始める攻撃対象領域の可視化とリスク対策~」
  • 最新情報はこちら


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る