タグ: セキュリティ

投稿日:

デジタル庁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の脆弱性悪用と侵害後の活動

出典：Cisco Talos「Active exploitation of Cisco Secure Firewall Management Center vulnerabilities」（https://blog.talosintelligence.com/fmc-ongoing-exploitation/）を基に弊社作成

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：修正版へのアップグレードと侵害調査 それぞれの目的

出典：Cisco「Cisco Secure Firewall Management Center Software Authentication Bypass Vulnerability」（https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-onprem-fmc-authbypass-5JPp45V2）「Cisco Secure Firewall Management Center Software Static Credential Vulnerability」（https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-fmc-static-cred-BET3Cjh）を基に弊社作成

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

侵害の疑いがあるときは、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日体制で監視・運用を支援します。アラートの検知だけでなく、その後の調査や対応を含めたセキュリティ体制についてもご相談いただけます。

G-MDR® について詳しく見る

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

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

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

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

【参考情報】

編集責任：木下

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

最新情報はこちら

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

投稿日:

2026年上半期のサイバー脅威情勢 ―ランサムウェア被害は半期最多123件に

Share
2026年上半期のサイバー脅威情勢アイキャッチ画像

警察庁が2026年9月10日に公表した「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」によると、ランサムウェアの被害報告は123件となり、2020年下半期の統計開始以降、半期として最多となりました。注目したいのは、被害件数だけでなく、侵入経路や被害後の復旧の実態です。本記事では、警察庁の公表資料をもとに、企業が押さえておきたいポイントと必要な対策を解説します。

ランサムウェア被害は半期最多123件

2026年上半期のランサムウェア被害報告件数は、前年同期の116件から7件増えました。増加率は約6.0％です。被害を受けた企業・団体等のうち、中小企業79件、大企業31件、団体等13件でした。中小企業が全体の約64％を占め、業種別では製造業が37件と最も多くなっています。*7[統計編141・142頁]

ランサムウェア被害報告件数の半期推移

出典：警察庁「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」（https://www.npa.go.jp/publications/statistics/cybersecurity/data/R8kami/R08_kami_cyber_jousei.pdf）統計データをもとに弊社作成

※本統計データは警察庁に報告された企業・団体等の被害件数であり、国内で発生したすべての被害を示すものではありません。

また、暗号化せずに盗んだ情報の公開をほのめかして金銭を要求する「ノーウェアランサム」は、別に9件報告されています。ランサムウェア被害を考える際には、データの暗号化だけでなく、情報窃取を伴う脅威にも注意が必要です。それでも、中小企業にも被害が広く及んでいる事実は、自社の規模を理由に対策を後回しにできないことを示しています。限られた人数で対策を進める企業ほど、インターネットに公開している機器と、停止した場合に仕事が進まなくなるシステムを具体的に洗い出すところから始めるのがよいでしょう。

感染経路はVPN機器が最多

警察庁の被害組織へのアンケートでは、感染経路の有効回答36件のうち、VPN機器が18件、リモートデスクトップが9件、その他が9件でした。VPN機器とリモートデスクトップで75％を占めました。ただし、感染経路について回答が得られた36件を対象とした結果です。*2[統計編143頁]

また、同報告書では、攻撃者が未修正の脆弱性や漏えいした認証情報などを悪用してネットワークへ侵入する手口が示されています*3[本文10頁]。そのため、「VPN機器からの侵入＝製品の脆弱性が原因」とは限りません。VPN機器などのソフトウェアの更新状況だけでなく、アカウントや認証の管理も併せて確認することが重要です。

こうした侵入への対策として、警察庁の「ランサムウェア被害防止対策」では、VPN機器等への更新ファイルの適用、認証情報の適切な管理、多要素認証やアクセス制限などを挙げています。これを日々の運用に落とし込むには、装置の製品名とバージョン、保守期限、更新の担当者を把握し、不要な公開設定や使われていないアカウントを見直すところから始めます。委託先が運用している場合も、更新を依頼するだけで終えず、適用結果を確認する役割を決めておきましょう。

公開機器の管理が重要となる背景には、脆弱な機器などを探す活動が継続的に観測されていることもあります。警察庁のセンサーが検知した脆弱性探索行為等の不審なアクセスは、1日・1IPアドレス当たり1万3,687件でした*4[本文5頁]。ただし、これは警察庁の観測環境における値であり、一般企業が毎日同じ件数の攻撃を受けていることを意味するものではありません。外部から接続可能な機器やサービスを継続的に把握し、不要な公開がないか定期的に確認することが重要です。

調査・復旧費用は1,000万円以上が6割

ランサムウェア被害に伴う調査・復旧費用の総額について、有効回答35件のうち21件が1,000万円以上でした。このうち4件は1億円以上です。身代金の要求額を示す統計ではなく、被害後の調査と復旧に要した費用である点を押さえておく必要があります。また、復旧等に要した期間は、有効回答48件のうち、1か月未満が23件、回答時点で復旧中が13件でした*5[統計編144・145・146頁]。

「復旧中」には終了時期が確定していない回答が含まれるため、残りを一括して「1か月以上停止した」と読むことはできません。また、システムの復旧期間と、全社の業務停止期間も同じではありません。

被害後の負担とバックアップ復元の実態

調査・復旧費用が1,000万円以上

60.0％

21件 ／ 有効回答35件

バックアップから復元できなかった

72.5％

29件 ／ 有効回答40件

出典：警察庁「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」をもとに弊社作成。割合は警察庁公表の件数をもとに弊社算出。
※項目ごとに有効回答数が異なるため、2つの割合を直接比較するものではありません。また、一般企業における被害率やバックアップの失敗率を示すものではありません。

被害後の調査や復旧には大きな費用が発生する場合があります。被害が発生してから対応を検討するのではなく、平時から復旧の優先順位や必要な対応を整理しておくことが重要です。

万一の費用負担に備えるサイバー保険

サイバー攻撃への備えでは、被害を防ぐための対策に加えて、万一インシデントが発生した場合の費用負担についても考えておくことが重要です。BBSecでは、SQAT® 脆弱性診断サービスにサイバー保険を付帯しています。情報漏えいやサイバー攻撃に起因する賠償損害や、事故発生時の対応にかかる費用損害などを補償し、平時のセキュリティ対策と万一への備えを支援します。

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

【関連記事】

バックアップは復元できる状態まで確かめる

バックアップからの復元結果に関する有効回答40件では、復元できたのは11件、できなかったのは29件でした*6[統計編148頁]。

バックアップを取得していても、被害発生時に必ず復元できるとは限りません。重要なのは、バックアップの有無だけでなく、保存先が攻撃の影響を受けにくい状態になっているか、実際にデータを復元できるか、復元後にシステムや業務を再開できるかまで確認しておくことです。警察庁もランサムウェア被害防止策として、バックアップをネットワークから切り離して保管することなどを呼びかけています*7。日常のバックアップ結果に加えて、復元の手順と所要時間を確認し、事業継続計画に反映させることが重要です。

さらに、暗号化されたデータを復元できても、盗まれた情報への対応は残ります。報告書によると、手口が判明した66件のうち61件は二重恐喝でした*8[本文98頁・統計編140頁]。二重恐喝とは、データの暗号化に加え、窃取した情報の公開を材料に金銭等を要求する手口です。バックアップの整備と並行して、持ち出された情報の範囲を調べ、関係者への説明に必要な事実を整理できるよう備える必要があります。

フィッシング報告は約73万件

フィッシング対策協議会の集計によると、2026年上半期のフィッシング報告件数は約73万件でした*9。なお、この数字は同協議会に寄せられた報告件数であり、被害者数や不正送金の件数を示すものではありません。前年同期を下回っているものの、引き続き多くのフィッシングが報告されており、継続した対策が必要です。

警察庁の報告書では、AI技術の発達により、文章や偽装が自然で見抜きにくいフィッシングへの注意を促しています*10[本文17頁]。そのため、「日本語が不自然なら疑う」といった見分け方だけに頼るのではなく、メールやSMSで手続きを求められた場合は、本文中のリンクからアクセスせず、公式サイトや公式アプリなど、確認済みの経路からアクセスすることが重要です。

企業側でも、従業員への注意喚起だけでなく、多要素認証の導入や不審なログインの監視など、認証情報が窃取された場合も想定した対策が求められます。フィッシング対策とランサムウェア対策は別の入口を持つことがありますが、認証情報の管理と異常の早期把握は、双方に関わる備えです。

ランサムウェア対策を事業継続につなげる

警察庁の報告書では、ネットワークへの侵入後に権限奪取や内部探索、情報窃取が行われ、暗号化に至る攻撃の流れが示されています*11[本文10頁]。こうした攻撃の流れを企業の対策に置き換えると、公開機器の管理から侵入後の監視、復旧の準備までを一続きで考えることが重要です。VPN機器などの更新や認証強化を進めるだけでなく、不審なログインや権限の悪用を把握し、速やかに封じ込めへ移れる体制を整えておく必要があります。

事業継続の準備では、どの業務を優先して再開するか、誰がシステムの切り離しや再接続を判断するか、社内システムが使えないときにどう連絡するかを具体化します。調査や封じ込めと調整しながら復旧を進める必要があるため、自然災害を想定した計画だけでは対応しきれない場面があります。

侵入への備えと事業継続をつなぐ対策

出典：警察庁「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」（https://www.npa.go.jp/publications/statistics/cybersecurity/data/R8kami/R08_kami_cyber_jousei.pdf）および「ランサムウェア被害防止対策」をもとに弊社作成

IT-BCPで復旧の優先順位を明確にする

ランサムウェア被害からの復旧では、システムを元に戻すだけでなく、どの業務を優先して再開するか、そのためにどのシステムから復旧するかをあらかじめ整理しておくことが重要です。また、調査や封じ込めの状況を踏まえながら復旧を進める必要があるため、復旧時の判断基準や役割分担も明確にしておく必要があります。

IT-BCPは、ITシステムが利用できなくなった場合の事業継続と復旧に備える計画です。BBSecでは、「ランサムウェアに対応したIT-BCP策定支援」を提供しています。現状の対策状況を確認し、復旧優先度や目標とする対策レベルを設定したうえで、システム・ネットワークの要件、運用要件、改善計画の具体化を支援します。「バックアップはあるものの、どのシステムから復旧するか決まっていない」「インシデント発生時の復旧判断や役割分担が明確になっていない」といった課題がある場合には、業務とシステムの関係を整理し、ランサムウェア被害を想定した復旧計画を検討しておくことが重要です。

[ランサムウェアに対応したIT-BCP策定支援の詳細・相談はこちら]

また、インシデント発生時の初動手順や体制を整備したい場合には「インシデント初動対応準備支援」、セキュリティ対策のログ監視・分析などの運用体制を強化したい場合には「G-MDR®」など、平時からの備えを組み合わせることも有効です。

【参考情報】

編集責任：木下

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

ランサムウェア対策やインシデント対応、事業継続に向けた備えなど、自社のセキュリティ対策についてお悩みの場合は、ブロードバンドセキュリティ（BBSec）までお気軽にご相談ください。

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

最新情報はこちら

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

投稿日:

AIガバナンスとは？企業に必要な体制とAI利用ガイドラインの作り方

Share
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の業務利用における個人情報や機密情報の取り扱いについて注意を促してきました。また、独立行政法人情報処理推進機構（IPA）が2026年7月に公開した「生成AIおよびAIエージェントを安全に活用するための手引書」では、全社AIガバナンスとして、AIガバナンス体制の整備、利活用ガイドラインの策定、シャドーAIへの対応方針などが整理されています。生成AIを一律に禁止するだけではなく、生成AIの利用実態を把握し、リスクに応じて適切に管理できる仕組みを整えることが重要です。

生成AIの情報漏洩や誤情報、著作権、サイバー攻撃への悪用などのリスクについては、「生成AIのリスクとは？企業が注意すべき情報漏洩・誤情報とサイバー攻撃への悪用」で詳しく紹介しています。

AIガバナンスを取り巻く国内外のルールとガイドライン

AIの急速な普及を受け、国内外ではAIを安全かつ適切に利用するためのルールやガイドラインの整備が進められています。日本では、経済産業省と総務省が2024年に「AI事業者ガイドライン」を策定しました。その後もAIを取り巻く環境の変化に応じて改定が続けられ、2026年3月には第1.2版が取りまとめられています。AI事業者ガイドラインでは、AIに関係する事業者をAI開発者、AI提供者、AI利用者に整理し、それぞれが取り組むべき事項などが示されています。

政府においてもAI利用のルール整備が進んでいます。デジタル庁は2026年6月、「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン」を第2.0版へ改定しました。同ガイドラインでは、政府における生成AIのガバナンスや、各府省庁が生成AIを調達・利用する際のルールなどが示されています。

個人情報の取り扱いについても注意が必要です。個人情報保護委員会からは2023年6月に「生成AIサービスの利用に関する注意喚起等」で一部事業者に対する要配慮個人情報の取得及び利用目的の通知などについての注意喚起が行われています。全般の注意喚起では個人情報取扱事業者、行政機関、一般利用者それぞれに向けた注意点が記載されています。

生成AIサービスを利用する場合には、利用規約やプライバシーポリシーを確認し、入力する情報がどのように取り扱われるのかを把握したうえで利用を判断することが重要です。

AIサービスの契約条件も確認する

AIサービスを導入する際には、社内ルールだけでなく、利用するサービスの契約条件やセキュリティについて確認することも重要です。経済産業省が公開している「生成AIサービスの利用・開発に関する契約チェックリスト」では、AIサービスの利用や開発にあたり、インプット・アウトプットの取り扱いや権利関係、責任分担などを確認するための観点が整理されています。

生成AIサービスの利用・開発に関する契約チェックリスト（チェッリストの対象となる条項）
チェックリストの対象となる条項
出典：経済産業省「AIの利用・開発に関する契約チェックリスト」p.11より抜粋

セキュリティに関してはチェックリスト内に、以下の観点でのチェック項目が設けられています。

  • 対象システム(AIサービス)のセキュリティ水準
  • 監査条項等
  • ログの保存
  • 規約改定に関する留意点

AIサービスを選定する際には、機能や価格だけでなく、入力した情報がどのように扱われるのか、ログが保存されるのか、契約条件が変更された場合にどのような影響があるのか、といった点も確認する必要があります。

海外でもAIに関する制度整備が進む

海外でもAIの安全性や信頼性を確保するための制度整備が進められています。代表的なものが2024年に施行されたEUのAI全般をリスクベースで管理するためのAI法（『EU AI Act: first regulation on artificial intelligence』）です。AI法では、AIシステムをリスクに応じて分類し、許容できないリスクを持つAIを禁止するとともに、高リスクAIにはリスク管理や記録、人による監督などの要件を設けています。

また、汎用目的AI（General-purpose AI（GPAI））についても、そのリスクや役割に応じた義務が設けられています。

日本企業であっても、EU域内でAIシステムを提供したり利用したりする場合などには適用対象となる可能性があります。海外で事業を展開する企業では、自社のAI利用に関係する国や地域の制度についても確認する必要があります。

さらにEU以外でも、韓国をはじめ各国でAIの安全性や信頼性を確保するための制度・体制整備（韓国：AI基本法等）が進んでいます。

こうした動きを踏まえると、AIガバナンスは一度ルールを作れば完了するものではありません。AI技術やサービス、国内外のルールの変化に応じて、自社の管理体制も継続的に見直していく必要があります。

AIガバナンスで企業が整えるべき体制

AIガバナンスを実際に機能させるためには、AI利用に関する役割と責任を明確にする必要があります。例えば、経営層がAI活用に関する基本方針や許容するリスクを示し、情報システム・セキュリティ部門が利用するAIサービスの安全性や情報管理を確認します。法務・コンプライアンス部門は、個人情報や著作権、契約などの観点から利用条件を確認し、各事業部門は定められたルールに基づいてAIを利用します。

重要なのは、必ずしも「AIガバナンス委員会」のような新しい組織を設置することではありません。企業の規模やAIの利用状況によっては、既存の情報セキュリティ委員会やリスク管理、ITガバナンスなどの体制に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やLLMを組み込んだシステムでは、プロンプトインジェクションをはじめ、生成AIの利用管理とは異なるセキュリティリスクにも注意が必要です。詳しくは、「LLMセキュリティとは？プロンプトインジェクションなどの脅威と対策」で紹介しています。

AIガバナンスはどこから始める？

AIガバナンスという言葉から、大規模な管理体制や複雑なルールを想像するかもしれません。しかし、最初からすべてを整備する必要はありません。まずは、自社でAIがどのように利用されているのかを把握することから始めます。

STEP1　自社のAI利用状況を把握する
どの部門が、どのAIサービスを、どのような業務に利用しているのか確認します。会社が正式に導入したAIだけでなく、従業員が個別に利用しているサービスについても把握することが重要です。

STEP2　利用するAIとリスクを整理する
入力する情報、生成物の用途、外部サービスへのデータ送信、AIに与える権限などを確認し、利用方法に応じたリスクを整理します。

STEP3　責任者・管理体制を決める
AI利用に関する方針を誰が決定し、セキュリティ、法務、業務上の問題をそれぞれ誰が判断するのかを明確にします。

STEP4　AI利用ガイドラインを策定する
利用できるAI、入力できる情報、生成物の確認方法、禁止する用途、問題発生時の報告方法などを具体化します。

STEP5　教育・確認・見直しを続ける
従業員へルールを周知するとともに、実際の利用状況を確認します。AIサービスや業務、脅威、法制度などの変化に応じてガイドラインを更新します。

AIガバナンスは完成させるものではなく、AIの利用とともに継続的に改善していく取り組みと考えることが重要です。

AIガバナンスに関するよくある質問

▼ AIガバナンスとAI利用ガイドラインの違いは？
▼ AI利用ガイドラインはどの部署が作るべきですか？
▼ 生成AIの利用を禁止すればAIガバナンスは不要ですか？

まとめ

生成AIをはじめとするAIの業務利用が広がるなか、企業にはAIを安全かつ適切に利用するためのガバナンスが求められています。AIガバナンスは、AI利用ガイドラインを作成することだけを意味するものではありません。AI利用に関する方針を定め、責任体制を明確にし、リスクを評価しながら、実際の利用状況に応じてルールや対策を継続的に見直していくことが重要です。

また、自社の利用ルールだけでなく、利用するAIサービスのデータの取り扱いや契約条件、セキュリティ、国内外の制度動向について確認することも必要です。まずは自社でどのようなAIが利用されているのかを把握し、利用目的や取り扱う情報、想定されるリスクを整理することが第一歩となります。そのうえで、自社の事業やAIの利用状況に合った体制とガイドラインを整備し、安全なAI活用につなげていくことが求められます。

【参考情報】

公開日：2025年4月9日
更新日：2026年9月16日

編集責任：木下

AIの安全な活用に向けた体制づくりをご支援します

ブロードバンドセキュリティ（BBSec）では、AIの業務利用に伴うセキュリティリスクや管理体制の整備など、企業のAI活用に関するご相談を承っています。自社のAI利用状況やセキュリティ対策の見直しをご検討の際は、お気軽にご相談ください。

Security Serviceへのリンクバナー画像
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エージェントによる投稿を発見したと報告しています*12。活動の中心はドイツ語の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に戻る

投稿日:

サイバー対処能力強化法とは？4つの柱と施行スケジュールをわかりやすく解説

Share
サイバー対処能力強化法とは？アイキャッチ画像

サイバー対処能力強化法は、重要インフラ等に対する重大なサイバー攻撃の被害を未然に防ぎ、拡大を抑えるため、官民連携、通信情報の利用、アクセス・無害化、政府体制を整える法律です。届出・インシデント報告などの主要規定は2026年10月1日に施行されますが、通信情報利用の中核規定は別の日に施行されます。

ニュースでは「能動的サイバー防御法」と呼ばれることもありますが、その名称の単独法があるわけではありません。また、民間企業が攻撃者へ反撃できる法律でもありません。本記事では、サイバー対処能力強化法とは何か、対象企業と施行日、企業に求められる対応を、政府の一次資料に基づいてわかりやすく解説します。

サイバー対処能力強化法とは

サイバー対処能力強化法は、正式には「重要電子計算機に対する不正な行為による被害の防止に関する法律」です。これと「同法の施行に伴う関係法律の整備等に関する法律」を組み合わせ、国民生活や経済活動、国と国民の安全に重大な影響を与え得るサイバー攻撃への対処能力を高めます。両法は2025年5月16日に成立し、同月23日に公布されました*3。制度の狙いは、攻撃を受けた組織だけに対処を任せるのではなく、事業者が把握したインシデント情報、国が持つ脅威情報、ベンダーが持つ脆弱性情報などを組み合わせ、被害の未然防止と拡大防止につなげることです。従来の「事故後の復旧」に加え、攻撃の兆候を早期に把握して先回りする考え方が強く打ち出されています。

制度を理解する4つの柱

政府の説明資料では、制度の全体像を「官民連携の強化」「通信情報の利用」「アクセス・無害化」「組織・体制整備」の4つの観点から整理しています。本記事でも、この4つに分けて制度の概要を見ていきます。

官民連携の強化

対象となる事業者は、特定重要電子計算機を導入した場合に製品名や製造者名などを届け出ます。また、特定重要電子計算機で一定のサイバーインシデントを認知した場合には、事業所管大臣と内閣総理大臣への報告が必要です。政府は報告情報などを整理・分析し、被害防止に必要な情報を事業者や関係機関へ提供します。守秘義務を伴う情報共有・対策のための協議会も設けられます。

通信情報の利用

国がサイバー攻撃に利用されるインフラを把握するため、通信利用者との任意の協定に基づく取得と、一定の国外関係通信を対象とする同意によらない取得の仕組みが設けられます。取得した通信情報については、人による知得を伴わない自動的な方法によって、サイバー攻撃との関連が認められる機械的情報を選別します。政府資料では、IPアドレスや指令情報などが「意思疎通の本質的な内容ではない情報」の例として示されています。

アクセス・無害化

一定の要件を満たす重大なサイバー攻撃については、警察が攻撃に使用されるサーバー等に対し、攻撃用プログラムの停止・削除などの無害化措置を行う仕組みが整備されます。また、外国政府を背景とする高度で組織的な攻撃などでは、自衛隊が対応する場合もあります。

詳しい要件や通信情報の利用との関係は、「能動的サイバー防御とは？通信情報の利用とアクセス・無害化」で詳しく解説します。

組織・体制整備

政府の司令塔機能も強化されました。内閣官房には国家サイバー統括室と内閣サイバー官が置かれ、サイバーセキュリティ戦略本部の体制も強化されています。通信情報の取扱いや無害化措置を監督するサイバー通信情報監理委員会は、2026年4月1日に設置されました。

施行日は2026年10月1日、ただし段階施行に注意

サイバー対処能力強化法は、すべての規定が同じ日に施行されるわけではありません。主要な規定は2026年10月1日に施行されますが、一部は先行施行され、通信情報の利用に関する規定は別の日に施行されます。主な施行スケジュールは以下のとおりです。

時期主な内容
2025年5月23日法律公布
先行施行政府の組織・体制整備など
2026年4月1日サイバー通信情報監理委員会の設置
2026年10月1日届出・インシデント報告など主要規定
別途政令で定める日通信情報利用に関する中核規定

特定重要電子計算機の届出、インシデント報告、官民協議会、情報の分析・提供、アクセス・無害化などの主要部分は、2026年10月1日に施行されます。しかし、通信情報の取得・利用に関する中核規定は別の施行区分です。法律上、公布から2年6か月を超えない範囲で政令により定める日から施行されるため、「2026年10月1日に全制度が一斉に始まる」と理解するのは正確ではありません。

制度は段階的に動き出しており、総則や基本方針、監督機関の設置など、先に施行された規定もあります。公開日が施行日をまたぐ場合は、「施行されます」を「施行されました」へ変更するだけでなく、通信情報利用の施行状況も別に確認する必要があります。

企業への影響は「直接的な義務」と「取引上の影響」に分かれる

企業への影響を考える際は、まず「自社が法律上の義務を直接負う事業者なのか」と、「対象事業者のベンダーや委託先として対応を求められる可能性があるのか」を分けて考える必要があります。特定重要電子計算機の届出とインシデント報告を直接義務付けられるのは、法律上の「特別社会基盤事業者」です。これは、経済安全保障推進法に基づいて指定された特定社会基盤事業者のうち、特定重要電子計算機を使用する事業者を指します。そのため、基幹インフラ分野に属する企業がすべて一律に対象になるわけではありません。

対象となる事業者やシステム、特定重要電子計算機を導入した場合の届出については、「サイバー対処能力強化法の対象企業と届出義務」で詳しく解説します。

報告対象、速報・詳報の期限、委託先やクラウドで発生した事象の扱いは、「インシデント報告の対象と期限」で確認できます。

ベンダーや委託先に法律上の届出義務が直接課されなくても、契約に基づく通知、ログや技術情報の提供、脆弱性対応を求められる可能性があります。ただし、本法がすべてのベンダーへ一律にログ保存等を義務付けているわけではありません。

まとめ

サイバー対処能力強化法では、官民連携、通信情報の利用、アクセス・無害化、政府の体制整備を通じて、重大なサイバー攻撃による被害を未然に防ぎ、拡大を防止する仕組みが整備されます。企業にとって特に重要なのは、自社が届出・インシデント報告の対象となるのかを確認し、対象となる場合には必要な情報を速やかに把握・報告できる体制を整えておくことです。また、対象事業者のベンダーや委託先にも、契約や取引を通じて対応が求められる可能性があります。次の記事から、「対象企業と届出」「インシデント報告」「通信情報の利用とアクセス・無害化」に分けて詳しく解説します。

よくある質問

▼ サイバー対処能力強化法はいつ成立しましたか
▼ 能動的サイバー防御法という法律があるのですか
▼ サイバー対処能力強化法はすべての企業が対象ですか

参考情報

編集責任：木下

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

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

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

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

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

最新情報はこちら

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

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