タグ: セキュリティ

投稿日:

タイムズカーで約660万アカウントの情報漏洩 ―本人確認書類の保管とWebセキュリティを考える

Share
タイムズカーで約660万アカウントの情報漏洩アイキャッチ画像

2026年9月、タイムズカーのWebシステムが不正アクセスを受け、約660万アカウントの情報漏洩が確認されました。続報では、運転免許証画像などの本人確認書類が漏洩したアカウント数が約160万件と公表されています。本記事では、公式発表をもとに被害の範囲と利用者への案内を整理し、会員情報を扱う企業が見直したいデータ管理とWebセキュリティについて考えます。

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

2026年9月にタイムズカーで何が起きたのか

タイムズカーは9月25日9時07分に不正アクセスを検知し、同日の第1報で個人情報漏洩の可能性を発表しました。翌26日7時25分までに侵入経路と攻撃元からの通信を遮断し、遮断後にアクセスできないことを確認したとしています。その後、28日の第2報で第三者による情報取得を確認したと公表し、調査の進展に伴って発表内容を更新しました。公式発表では、具体的な侵入手法や悪用された脆弱性の詳細は示されていません。同社は外部専門機関による原因・影響範囲の調査を進め、再発防止策は続報で公表する方針です。また、サービス提供への影響は確認されず、通常どおり継続していると説明しています。サービスの稼働状況と個人情報への影響は、それぞれ確認する必要があります。

約660万件と約160万件、それぞれの対象範囲

第2報の約660万件は、漏洩したアカウントの数です。対象にはタイムズカーの会員と退会者、入会手続きが完了していない申込者のほか、タイムズビジネスサービスの会員と退会者も含まれます。現在利用している会員だけの人数として受け取らないことが大切です。漏洩した情報の項目については、公式FAQでも詳細が示されています。氏名、住所、生年月日、電話番号、メールアドレスに加え、法人会員の所属部署名、運転免許情報、本人確認書類情報、パスワード、連携サービスIDが挙げられています。一方、クレジットカード情報は保有しておらず、今回の対象には含まれないと説明しています。

9月29日の第3報で示された約160万件は、運転免許証画像などの本人確認書類が漏洩したアカウント数です。書類には現住所確認書類、学生プランの学生証、家族プランの家族確認書類の画像も含まれます。約660万件と約160万件は数えている情報の範囲が異なるため、単純に足して被害規模を示すことはできません。同社はパスワードを復元できない形式で保存していたと説明し、パスワードそのものが第三者に認識できる状態で漏えいした事実は確認していないとしています。不特定多数への情報公開や、本件に起因する不正利用も公表時点では未確認です。これらは同社が示した調査状況として読み、今後の更新も確認する必要があります。

図：タイムズカーで確認された情報漏洩の範囲

タイムズカーで確認された情報漏洩の範囲
出典：タイムズモビリティ株式会社 第2報（2026年9月28日）・第3報（2026年9月29日）をもとに作成
※約160万件は約660万件に含まれます。いずれもアカウント数で、対象となる情報は利用者によって異なります。

利用者は個別通知と公式窓口を確認する

本人確認書類の漏えいが確認された会員への個別メールは9月29日から始まりました。第3報では、詳細について外部専門機関の調査結果を踏まえ、2週間程度を目途に改めて案内する方針を示しています。その後、10月1日にはFAQと退会者向けの問い合わせ案内が追加され、退会者への通知も同日から順次開始されたと説明されています。

同社は、会社を装ったメールやSMS、電話への警戒を求めています。心当たりのない連絡に含まれるリンクや添付ファイルを開かず、パスワード、認証コード、クレジットカード情報を入力しないことが基本です。通知の内容や対象かどうかに疑問がある場合は、公式発表から問い合わせ先を確認してください。同社がメール、SMS、電話でパスワードやカード情報を尋ねることはないと案内しています。

本人確認書類は保有目的とアクセス権限を一緒に見直す

ここからは本件の原因を推定するものではなく、今回の事例を踏まえて、個人情報を扱う企業が確認したい一般的な対策を整理します。本人確認のために受け取る画像についても、会員台帳と同様に、何を、どこで、何のために保有しているかを把握することが出発点になります。退会や申込中断を含む業務の各段階とデータの保管場所を対応させ、取扱責任者や閲覧できる担当者まで確認すると、見直す対象が具体的になります。

10月1日の公式FAQでは、タイムズカーは氏名・住所・生年月日を税法等に基づき7年間、運転免許情報と画像をなりすまし対策や問い合わせ対応のため7年間保管すると説明しています。保有データを点検する際は、このように項目ごとに保管の理由を確認する視点が必要です。退会情報があることだけで、個別企業の保管の適否や漏えい原因を判断することはできません。

一方、個人情報の保存期間について、個人情報保護委員会のFAQでは、個人情報保護法が一律の保存期間や廃棄時期を定めているわけではないと説明しています。そのうえで、利用する必要がなくなった個人データは遅滞なく消去するよう努める必要があるとしています。自社では、保存の根拠と業務上の必要性を確かめ、期限を決めるだけで終わらせず、削除の対象を抽出して処理できる運用になっているか確認したいところです。

保管が必要なデータには、業務に応じたアクセス制御が欠かせません。個人情報保護委員会の通則編ガイドラインも、担当者や取り扱うデータの範囲を限定すること、正当なアクセス権を持つ従業者を識別・認証することを求めています。本人確認担当、問い合わせ担当、システム管理担当で必要な権限を整理し、画像を閲覧・取得できる範囲が過大になっていないか点検することが、企業向けの具体的な確認例になります。

個人情報を扱うWeb機能を継続して点検する

保存ルールや社内権限の確認に加え、利用者からデータへ至る機能も検証する必要があります。会員登録、ログイン、登録情報の変更、書類のアップロードなど、個人情報を扱う処理を洗い出し、どの処理を点検済みか整理します。APIを利用している場合は、その通信や処理も対象に含めます。本件でAPIが悪用されたと確認されたわけではなく、ここで挙げるのは自社システムを点検する際の観点です。

たとえば、本人がログインできることと、その本人に許可された情報だけを閲覧できることは、確認すべき内容が異なります。ログイン時の認証、ログイン状態を維持するセッション、ユーザー権限、重要情報の取り扱いを関連づけて確認することで、画面の通常操作だけでは見えにくい問題の検証につながります。本人確認画像を扱う機能を追加・変更したときにも、その機能を含めて診断範囲を見直すことが考えられます。

点検は新規公開時だけで完了するものではありません。個人情報保護委員会のガイドラインは、システムの設計段階で安全性を確保し、継続して見直すことを対策の例に挙げています。自社の改修予定と診断計画を合わせ、見つかった課題の担当者と修正予定を決め、修正後の確認まで行う運用に結びつけることが重要です。

個人情報の管理とWebの安全性をあわせて見直す

ここまで挙げたWeb側の確認を自社だけで行うことが難しい場合は、外部の脆弱性診断を活用する方法もあります。ブロードバンドセキュリティ（BBSec）では、「Webアプリケーション脆弱性診断」を提供しています。同サービスは、自動診断と技術者による手動診断を組み合わせ、検出した問題の深刻度と推奨対策を報告するサービスです。Webアプリケーションに加え、APIもオプションとして診断できます。会員登録やログイン、登録情報の変更、書類のアップロードなど、個人情報を扱う機能を含め、どこまでを診断対象とするかについてサービスページから相談できます。

個人情報を扱う体制や運用から整理したい企業には、「自己問診型 個人情報に関わる情報セキュリティアセスメント」も用意されています。オンラインの自己問診をもとにコンサルタントが評価し、課題や優先順位、対策案を示すサービスです。データを保有する理由と扱い方を整理する作業を、Web機能の技術的な点検と併せて進めることで、自社で優先すべき改善を具体化できるでしょう。

【参考情報】

個人情報を扱うWebサイトのセキュリティや、情報管理の体制・運用に課題を感じている場合は、現在の対策状況に応じた確認方法をご案内します。まずはお気軽にご相談ください。

編集責任：木下

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

最新情報はこちら

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

投稿日:

Gyazoの情報漏洩から考える ―画像メタデータと削除後のデータ管理

Share
Gyazoの情報漏洩から考える ―画像メタデータと削除後のデータ管理アイキャッチ画像

画像共有サービス「Gyazo」で2026年9月に発生した不正アクセスでは、ユーザー関連データに加え、画像に付随するメタデータの流出が確認されました。第二報では、過去に削除した画像のメタデータも対象だったことが明らかになっています。公表された数値を被害人数や画像本体の流出件数と取り違えず、画像と関連情報を一体で守る視点が必要です。本稿は公式情報を基に、影響と対策を整理します。

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

Gyazoへの不正アクセスの概要

運営会社のHelpfeelによると、9月11日、画像アップロードサーバーの脆弱性を悪用した第三者が、システム上で任意のコマンドを実行しました。同社は同日夜に異常を検知し、12日未明までに確認された侵入経路と不正な接続を遮断しました。その後、データベース内のユーザー情報と画像メタデータの流出を確認しています。公表内容から、脆弱性の具体的な種類や開発・運用上の原因まで断定することはできません。

同社は二次被害防止のため画像配信の停止などを実施し、サービス提供も一時停止しました。追加の検証と対策を経て、9月27日にサービスを再開しています。再開後も調査と対策は継続する方針です。また、第二報時点で「Helpfeel」「Cosense」のシステムからの情報漏洩や攻撃の痕跡は確認されていません。これらのサービス上でGyazo画像を表示できない影響と、各サービス自体の侵害は区別する必要があります。

約2,362万件のユーザー関連データが流出

流出したユーザー関連データは約2,362万件です。第二報の内訳は、メールアドレス未登録の匿名ユーザーが約1,801万件、登録のあるユーザーが約562万件でした。丸め処理により内訳の合計は総数と一致しません。この数値はデータの件数であり、そのまま個人情報が漏洩した人数や国内の被害人数を表すものではありません。対象情報には、名前、メールアドレス、パスワードのハッシュ値、利用者ID、ログインセッションIDなどがありますが、含まれる項目はユーザーごとに異なります。クレジットカード番号などの決済情報は含まれていません。流出対象とされたX連携用トークンも、第二報では単体でXへのログインや操作はできないと確認され、関連するOAuth認証情報は予防的に無効化されています。

画像メタデータと削除済み画像への影響

画像に関して公表されたのは、主に2019年1月以前にアップロードされた画像のメタデータ約4.9億件と、条件を絞って取得された240万件です。第二報では、削除済み画像のメタデータ約1.74億件も加わりました。いずれも画像ファイル本体の流出件数ではなく、これらの数値から画像ファイル本体の流出・閲覧状況や、その対象数を判断することはできません。第一報では、流出したメタデータに画像URLを構成する情報が含まれており、それを用いて画像が不正に閲覧されるおそれがあることや、非公開画像のファイル一覧が取得されていたことも公表されています。一部の非公開画像が第三者に閲覧された可能性についても、完全には否定できないとされています。

削除済み分は、主に2023年2月以前に画像またはアカウントを削除したものです。基準となる時期はアップロード日ではありません。対象の画像ファイルは閲覧できない状態で、今回追加で確認された流出に削除済み画像の本体は含まれていないと説明されています。一方、画像に関連する情報は残り、流出対象となっていた点が、データ管理を考える上での重要な論点です。

メタデータには、画像URLを構成する画像ID、アップロード元IPアドレス、User-Agent、OCRテキスト、画像タイトル、取得元URL、画像に含まれる場合の位置情報、非公開画像のパスフレーズ（ハッシュ値）などが含まれます。画像そのものではなくても、内容や利用状況に関わる情報を持ちます。第一報では、流出情報を使った画像の不正閲覧のおそれや、一部の非公開画像が閲覧された可能性も示されています。「メタデータだけだから影響は小さい」と判断することは適切ではありません。

図：Gyazoで流出したユーザー関連データと画像メタデータ

Gyazoで流出したユーザー関連データと画像メタデータ
出典：Helpfeel「「Gyazo」への不正アクセスによる情報漏えいに関するお知らせとお詫び（第二報）」（https://corp.helpfeel.com/news/news-20260925-01）を基に弊社作成。
※ユーザー関連データと画像メタデータは集計対象が異なります。各数値は被害人数や画像ファイル本体の流出件数を示すものではありません。ユーザー関連データの内訳は概数のため、合計と総数が一致しない場合があります。

利用者が確認したいポイント

利用者向けには、Gyazoのパスワード変更と、同一または類似したパスワードを使う他サービスの変更が案内されています。本件を装う不審なメールやメッセージにも注意が必要です。変更や確認は、公式サイトと公式ヘルプの案内に沿って進めてください。再開時には、不正アクセス発生前の画像を原則として所有者だけが閲覧できる状態とし、利用者自身が配信の再開を選ぶ方式が採られました。再開すると従来の閲覧範囲が適用されるため、業務情報や個人情報が写っていないか、共有先が適切かを確認してから操作することが大切です。なお、9月29日の追記ではGyazo Teamsについて、配信停止中でも同じチームのメンバーが閲覧できる仕様変更が示されています。「自分のみ」の画像は対象外で、パスワード保護画像には引き続きパスワードが必要です。

無料プランでも、特別措置として発生前にアップロードした過去の画像を確認できます。ただし、公式ヘルプでは、配信を再開した画像をアクセス制御で再び本人だけに限定する機能は、現時点でProとTeamsのみとされています。無料プランの利用者は、まとめて再開する前にこの制約も確認してください。

企業が見直したいデータ管理

ここからは、本件の原因の推定ではなく、画像やファイルを扱う企業への一般的な提案です。まず、保護対象を画像本体だけに限定せず、OCR結果、位置情報、タイトル、識別子などの関連データまで洗い出します。どこに何の目的で保存し、誰が参照できるかを整理すれば、画像を削除した後に何が残る設計なのかも点検しやすくなります。今回、削除済み画像の関連情報まで流出対象となったことは、自社で「削除後にどのデータが残るのか」を確認する一つの契機になります。

削除機能の確認では、画面から見えなくなることと、関連データの保存が終了することを分けて考えます。業務上の必要に応じて保存期間と削除対象を定め、画像の削除時や退会時に、関連情報が想定どおり処理されるかまで確かめることを提案します。例えば、画像削除後にOCR検索や管理画面から関連情報が参照できるか、保存期限後に不要な情報が残らないかを検証します。保存を続ける情報には、その理由と閲覧権限を明確にします。

さらに、画像URLや識別子を知っていることだけに保護を頼らず、情報の機密性に応じて閲覧者の権限を確認する設計が必要です。OWASPも、リクエストごとの権限検証と、画像などの静的なファイルを含めたアクセス制御を推奨しています。共有範囲の変更、退会、チームからの離脱など、利用者の状態が変わる場面をテストに含めると、権限の残り方を確認できます。

設計レビューと脆弱性診断を活用する

アップロード機能は、受け入れるファイルの種類、処理に使うライブラリ、保存先、ファイルや処理プロセスに与える権限をまとめて確認したい領域です。OWASPは、ファイル形式の検証、ライブラリの安全な設定と更新、最小限の権限などを組み合わせる対策を示しています。開発時に決めた安全要件が、改修後や運用中も満たされているかを継続して検証することが大切です。

ブロードバンドセキュリティ（BBSec）の「Webアプリケーション脆弱性診断」は、外部からの動的診断に自動ツールと手動診断を組み合わせ、攻撃の入口となり得る問題箇所を確認します。API診断もオプションで提供しています。また、「Shift Leftコンサルティング」は、要件定義や設計のレビュー、開発標準・ガイドラインの作成を支援します。既存システムの脆弱性を確認したい場合は「Webアプリケーション脆弱性診断」、開発上流工程からセキュリティ要件や設計を見直したい場合は「Shift Leftコンサルティング」をご活用いただけます。自社のシステムや開発状況に応じた対策について、BBSecへお気軽にご相談ください。

【参考情報】

編集責任：木下

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

最新情報はこちら

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

投稿日:

佐川急便「お荷物問い合わせサービス」に不正アクセス、個人情報流出の可能性

Share
佐川急便「お荷物問い合わせサービス」に不正アクセス、個人情報流出の可能性アイキャッチ画像

佐川急便は2026年9月30日、Webサイトの「お荷物問い合わせサービス」で第三者による不正アクセスを確認したと発表しました。10月1日の第2報では個人情報が外部に流出した可能性を公表し、同日の第3報で専用コールセンターの開設を案内しています。対象には荷物の送り主と届け先、運賃契約者、スマートクラブ登録者の情報が含まれる可能性があり、件数や影響範囲、原因の調査が続いています。本記事では、公表された事実と、企業が同様の事態に備えて確認しておきたい対応を整理します。

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

不正アクセス確認から個人情報流出の可能性公表まで

第1報によると、不正アクセスを確認した日は9月30日です。佐川急便は確認後に同サービスへのアクセスを一部制限し、荷物の問い合わせが利用しづらくなる場合があると案内しました。翌10月1日の第2報では、調査によって個人情報の外部流出の可能性が判明したと説明し、被害拡大を防ぐために一部のWebサービスを停止していることを公表しています。

その後の公表でも、影響範囲と原因は引き続き調査中とされています。確認できた公表内容からは、侵入に使われた具体的な手法や脆弱性、対象人数を確定できません。「不正アクセスを確認したこと」と「個人情報が流出した可能性」を分けて捉える必要があります。公表されていない攻撃経路を推測し、自社の対策を特定の製品や手法だけに絞ることも避ける必要があります。

流出した可能性がある情報と「約100日間」の意味

第2報では、対象となる可能性がある人と情報を三つに分けています。荷物の送り主と届け先については、氏名、住所、電話番号が対象とされ、法人の場合は法人名と担当者名が含まれます。この区分について、9月30日からさかのぼる約100日間の累計データと説明されています。運賃契約を結んでいる法人・個人についても、氏名または法人名と担当者名、住所、電話番号が挙げられています。スマートクラブ登録者については、氏名、住所、電話番号に加え、メールアドレスと会員IDが対象とされています。一方、クレジットカード情報とパスワードは含まれないとしています。対象件数と範囲は調査中です。

ここでいう「約100日間」は、荷物の送り主・届け先に関する対象データの説明です。不正アクセスが約100日間継続していたという意味ではありません。 また、運賃契約者やスマートクラブ登録者にも一律に適用される期間とは示されていません。対象には荷物の届け先も含まれる可能性があるため、自ら発送や会員登録をしていない場合でも、届け先として情報が登録されている可能性があります。個々の対象については、今後の佐川急便の公式案内を確認する必要があります。

図：佐川急便が公表した流出可能性の対象

出典：佐川急便「「お荷物問い合わせサービス」への不正アクセスによる個人情報流出の可能性について（第2報）2026年10月1日」（https://www2.sagawa-exp.co.jp/information/detail/420/）を基に弊社作成。
いずれも流出した可能性がある情報であり、流出の確定や対象人数を示すものではありません。「約100日間」の記載は、送り主・届け先の区分に付されたものです。

Webサービスの停止と集荷・配達の状況を区別する

第2報の停止対象には、インターネット貨物お荷物問い合わせとそのAPI、飛脚宅配便受付、飛脚往復便受付と同ゴルフ受付、商品回収返金サービス、配達予定時・不在発生後の受取先変更、回収くんが挙げられています。一方、荷物の集荷・配達は通常どおり行っていると説明しています。Webで追跡や手続きができないことと、配送そのものが停止していることは分けて捉える必要があります。

第3報では、個人情報流出の可能性に関する専用コールセンターの開設も案内されています。受付時間など最新の問い合わせ方法については、佐川急便の公式案内を確認してください。集荷や配達状況など荷物に関する問い合わせについては、最寄りの営業所へ連絡するよう案内されています。

佐川急便は、同社を装う不審な連絡への注意も呼びかけています。不審な連絡に記載されたURLへのアクセスや、個人情報の入力・提供をしないよう注意が必要です。利用者向けに案内する企業も、佐川急便からの注意喚起と公式窓口を共有し、追加情報の確認先をそろえておくとよいでしょう。

配送を委託する企業は顧客情報の受け渡しを確認する

今回の公表を受け、配送を利用する企業が自社の備えとして確認したいのは、どの業務で、誰の情報を、どの相手に渡しているかです。例えばEC事業では、購入者と届け先が異なる場合があります。発送担当者の情報だけを確認しても、顧客への説明に必要な範囲を把握できるとは限りません。ここからは佐川急便の調査結果とは切り分け、配送データを扱う企業が平時から確認しておきたい一般的な備えについて整理します。

配送会社に渡している情報を整理する

まず、自社の受注記録や出荷記録と、配送会社に渡す情報の項目を対応づけます。注文番号、発送日、送り状番号などを使って、対象期間の出荷と届け先を社内で確認できる状態を整えておきます。これは流出を確定する作業ではなく、配送会社から追加情報が示されたときに、自社との関係を確認するための準備です。整理した資料にも個人情報が含まれるため、閲覧できる担当者と共有先を定めて扱いましょう。

関係部門で確認状況を共有する

配送会社や業務委託先との連絡では、対象期間、情報項目、確認済みの内容、調査中の内容を記録します。社内でも物流、情報システム、顧客対応などの関係部門で情報を共有し、顧客への説明や公表を誰が判断・承認するかを決めておくことが重要です。調査中の事項を断定せず、情報の更新日時と確認中の事項を明確にすることで、社内外への説明の食い違いを抑えられます。

影響範囲を調べられるログと初動の役割分担を備える

自社でWebサービスや配送連携システムを運用している場合は、異常を検知した後に何を調べられるかも確認しておきたい点です。JPCERT/CCは、複数のサーバーや機器のログを適切に採取・分析することで、侵入や攻撃の影響範囲を捉えられる可能性があると説明しています。一方、必要なログが取得されていない、または十分な期間保存されていないため、全容を解明できなかった例についても触れています。

そのため、ログを保存するだけでなく、どのシステムの、どの操作を確認するために記録するのかを決めておくことが重要です。アクセス時刻や利用アカウント、データの参照・出力に関する記録を実際に取得できるか確認します。保存期間や上書きされる条件、ログを取り出す担当者も整理しておけば、調査を始める際の迷いを減らせます。記録に痕跡が見つからない場合には、そもそもその操作を記録できる設定だったかを確かめることも必要です。

こうした技術面の準備と併せて、異常の受付、深刻度の判断、サービスの停止や制限を決める責任者、委託先への連絡担当を定めておきます。調査に必要な記録の保全と、顧客対応に必要な事実の整理を並行して進められる体制が望まれます。今回の事案で公表されている原因や対応の評価とは切り分け、自社で同様の連絡を受けた場合に必要な情報と判断を点検しておくことが、具体的な備えにつながります。

インシデントに備えてログと初動対応を見直す

ログの取得範囲や分析方法を整理したい場合は、BBSecの「セキュリティログ分析／活用支援」が選択肢になります。既存ログの分析、取得環境の整備に向けた助言、統合ログ管理・分析環境の構築から運用までを支援するサービスです。自社の記録で何を確認でき、どこに不足があるかを検討する際に活用できます。また、「インシデント初動対応準備支援」では、企業の現状に合わせ、初動対応フローやガイドラインの作成を支援します。調査の根拠となるログと、関係部門が動くための手順を平時から整えておきたい企業は、ブロードバンドセキュリティ（BBSec）にご相談ください。

【参考情報】

編集責任：木下

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

最新情報はこちら

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

投稿日:

AIはSIに変わったのか ―米国の呼称変更とASIの違いから考えるAIセキュリティ

Share
AIはSIに変わったのかアイキャッチ画像

「AIがSIに変わった」――2026年9月、そんなニュースが注目を集めました。米国では、トランプ大統領が従来のArtificial Intelligence（AI）をSuper Intelligence（SI）と呼ぶ方針を示し、9月29日には連邦行政機関でSIの呼称を使用する大統領令が発令されました。一方、中国側の公式発表では引き続き「人工知能」と表記されています。ここで注意したいのは、米国政府が使う「SI」と、AI研究で語られてきた「ASI（Artificial Superintelligence）」は同じ意味ではないことです。言葉の変化と技術の進化を切り分けたうえで、企業がいま向き合うべきAIセキュリティ上の課題を考えます。

米国はAIからSIへ　中国側は「人工知能」と表記

発端は9月22日の国連総会でのトランプ米大統領の発言です。米ホワイトハウスが公開した演説の抜粋には、従来「Artificial Intelligence」と呼んでいた技術を今後「Super Intelligence」と呼ぶ趣旨が記されています。その後、9月25日のホワイトハウスの成果文書は、米中首脳が対象となる新興技術について「artificial intelligence」ではなく「super intelligence」を用いることで合意したと発表しました。米中SI対話を設け、リスクと便益について意見を交換し、関連事案の連絡経路も設けるとしています。次回の対話は同年11月までと記されています。

一方、中国外交部が翌日に公表した「八点成果共識」では、同じ対話と事案の連絡経路について「人工智能」と記載されています。また、呼称について問われた中国外交部の報道官は、米国側の立場を重視し、その呼称を尊重するとの見解を示しました。中国側の公式発表では引き続き「人工智能」が使われており、米中間で対話の枠組みが確認された一方、両国の公式文書で使用される呼称は異なっています。

さらに9月29日、トランプ大統領は大統領令「Inaugurating the Era of Super Intelligence」に署名しました。大統領令では、連邦行政機関が公式文書やWebサイト、報告書などで「Artificial Intelligence（AI）」に代えて「Super Intelligence（SI）」を使用する方針が示されています。ただし、この大統領令におけるSIは、当面、米国法ですでに定義されているAIが包含する技術やシステムを指すとされています。つまり、米国政府がAIからSIへ呼称を変更したことと、技術的に「超知能」が実現したことは分けて考える必要があります。

SIとASIは同じ超知能を意味するのか

混乱を招くのは、Super Intelligenceという表現が、AI研究で長く論じられてきたsuperintelligence（超知能）を連想させる点です。哲学者ニック・ボストロムは、科学的創造性や社会的能力を含む、実質的にあらゆる領域で最も優れた人間の知能を大きく上回る知性として定義しました。人工的な超知能を表す際にはASI（Artificial Superintelligence）という略語も使われます。

9月29日の大統領令では、当面のSIについて、既存法で定義されているAIが包含する技術・システムを指すと明記されています。特定のモデルがASIに到達したという性能評価や技術上の達成を発表したものではありません。また、AGI（汎用人工知能）も別の概念です。例えばOpenAIは、多くの経済的価値のある仕事で人間を上回る高度に自律的なシステムと定義していますが、AGIの定義が一つに統一されているわけではありません。

表記指すもの今回のニュースとの関係
AIArtificial Intelligence（人工知能）の総称中国側の公式文書では「人工知能」と表記。既存の技術資料などでも広く使用されている
SI米政権がAIに代えて使用するSuper Intelligenceの呼称米国ではAIに代わる呼称として採用。ASIへの技術的な到達を意味するものではない
AGIArtificial General Intelligence（汎用人工知能）の概念今回のSIへの呼称変更がAGIの実現を示すわけではない
ASIArtificial Superintelligence（人工超知能）の概念人間の知能を大きく上回る知性を指す文脈で使われる。今回の米国政府によるSIの呼称とは同一視できない

名前が変わっても企業のAIセキュリティ課題は変わらない

「超知能」という言葉に目を奪われがちですが、企業がまず確認すべきなのは、現在導入している生成AIやAIエージェントが、どの情報を読み、どのシステムを操作できるかです。外部のWebページや文書を読み込むAIには、そこに紛れ込んだ不正な指示で本来の動作を変えられるプロンプトインジェクションのリスクがあります。OWASPは、外部コンテンツによる間接的な攻撃や、権限を与えすぎたエージェントによる意図しない操作を具体的なリスクとして挙げています。たとえば社内文書を検索して回答する仕組みと、メール送信や顧客データ更新まで実行できる仕組みでは、同じ不正な指示を読み込んでも影響が異なります。利用目的に合わせてアクセス権を最小限にし、重要な操作には人の承認を挟み、ツールの実行履歴を確認できるようにすることが重要です。こうした対策は、AIを何と呼ぶかによって変わりません。

米中間で設けるとされた事案の連絡経路も、企業の個別の事故対応手順を代替するものではありません。自社では、利用するAIサービス、投入するデータ、外部連携、権限、異常時の停止・連絡先を整理しておく必要があります。NISTの生成AI向けリスク管理資料も、設計から利用・評価まで組織的にリスクを扱うための枠組みを示しています。

AI利用のルールと技術面を一緒に見直す

今回の一連の発表では、米国側がSIという呼称を採用するとともに、米中間でAIのリスクと便益について協議する枠組みが示されました。一方、こうした呼称や政策上の動きとは別に、企業では現在利用しているAIの状況を把握し、入力情報の扱い、権限設定、人による確認、インシデント発生時の対応などを継続的に見直すことが求められます。

BBSecは、AIサービスの提供者・利用者を対象としたセキュリティガイドラインの整備支援など、AI利用におけるセキュリティ対策を支援しています。自社のAI利用ルールやシステム上の対策について、見直し方や進め方にお困りの場合は、お気軽にご相談ください。

関連記事：

AIエージェントのセキュリティ対策を詳しく知りたい方へ
AIエージェントに与える権限や外部通信、人による承認、操作ログなど、企業が確認しておきたいセキュリティ対策を事例とともに解説しています。
「OpenAIのAIエージェントが外部Wikiへ書き込み ―企業が見直すべき権限・通信・監視」

【参考情報】

編集責任：木下

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

最新情報はこちら

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

投稿日:

EvilTokensとは？Microsoft 365を狙うデバイスコードフィッシングとAI悪用

Share
EvilTokensとは？アイキャッチ画像

Microsoft 365の正規のサインイン画面を利用し、利用者に攻撃者側のアクセスを承認させる「デバイスコードフィッシング」が悪用されています。Microsoftが2026年9月に活動基盤を妨害した「EvilTokens」は、この手口によるアカウント侵害に加え、AIを使って侵害した受信箱を分析し、詐欺の標的やなりすまし相手を選ぶ機能も備えていました。本記事では、EvilTokensの仕組みと、Microsoft 365を利用する企業が確認しておきたい認証設定、監視、侵害後の対応について解説します。

EvilTokensとは

EvilTokensは、デバイスコードフィッシングによるアカウント侵害や、AIを使った侵害後の情報収集などを支援するPhishing-as-a-Service（PhaaS）プラットフォームです。Microsoftは2026年9月22日、同サービスの活動基盤を妨害したと発表しました。同社によると、世界の1万を超える組織で、1万2,000を超える受信箱が侵害されています。この数字はメール侵害の規模を示したものであり、金銭被害が発生した組織数を示すものではありません。

Microsoft 365を利用する企業が見直したいのは、認証画面のURLだけで安全を判断する運用です。EvilTokensは、利用者に正規のMicrosoftの画面で操作させ、攻撃者が開始した認証要求を承認させます。アカウントを守るには、MFAの導入に加え、自社で利用を認める認証方式や、侵害が疑われた場合の対応を確認する必要があります。

正規の認証画面でも侵害につながる理由

デバイスコード認証は、入力操作に制約のある機器などへサインインするための仕組みです。機器側に表示されたコードを、別の端末のブラウザーで入力して認証を完了します。デバイスコードフィッシングでは、この認証要求を攻撃者が開始し、コードを利用者に入力させます。問題は、コードにひも付く認証要求の主体です。画面自体がMicrosoftの正規サイトでも、そこで承認する要求が攻撃者によって開始されたものであれば、攻撃者側にアクセスが与えられます。偽サイトへパスワードを送信していなくても成立する手口です。利用者がMicrosoftにサインインしていない場合には、正規の画面でパスワードやMFAによる認証を求められることがあります。MFAを設定していても、利用者が攻撃者の要求を正規の認証画面で承認すると、侵害につながる場合があります。

図1：EvilTokensによるデバイスコードフィッシングと侵害後の流れ

出典：Microsoft「Disrupting EvilTokens: The AI Chatbot Built for Cybercrime」「Unmasking EvilTokens: Getting to the root of device code phishing」を基に弊社作成
※図は攻撃の概略を示したものです。AIによる分析後に、必ずなりすましや金銭被害が発生することを示すものではありません。

AIは受信箱から取引関係や送金担当者を探す

EvilTokensのAI機能は、侵害した受信箱を解析し、支払いに関する会話や組織内の役割、信頼関係などを把握するためにも使われていました。Microsoftは、詐欺の標的やなりすまし相手を選び、詐欺の進め方を提案する機能を報告しています。AIが、フィッシングメールの作成だけでなく、侵害した受信箱から詐欺に利用できる情報を探すためにも使われた事例です。このため、ビジネスメール詐欺対策では、振込先の変更や通常と異なる送金依頼について、信頼できる別の連絡経路で確認することが欠かせません。Microsoftも別経路での確認を推奨しています。実務では、受信メールに記載された連絡先をそのまま使わず、社内で管理している既知の連絡先で確認する運用が考えられます。

EvilTokensへの対策

図2：EvilTokensへの防御と対応

出典：Microsoft「Disrupting EvilTokens: The AI Chatbot Built for Cybercrime」、Microsoft Learn「Block authentication flows with Conditional Access policy」「Token theft playbook」「Respond to a compromised cloud email account」を基に弊社作成
※対策の分類は、Microsoftの公表資料を基に弊社が整理したものです。

不要なデバイスコード認証を制限する

予防策の出発点は、自社でデバイスコードフローを使っているかを把握することです。Microsoftは、利用状況を監査して必要性を判断し、可能な限り利用を遮断する方針を推奨しています。業務上必要な用途がある場合は、その理由と保護方法を明確にし、例外を限定します。Microsoft Entra IDの条件付きアクセスでは、認証フローを条件としてデバイスコードフローをブロックできます。変更時は、レポート専用モードで影響を確認してから有効化します。緊急アクセス用アカウントなど必要な除外を設計し、例外が増え続けないよう定期的に点検することも重要です。従業員向けの説明にも、この仕組みを反映することが重要です。「URLを確認する」に加え、「自分が開始していないサインインのコードは入力しない」と具体化すれば、何を判断すべきか伝わりやすくなります。これは、今回の認証手口を踏まえた教育上の対策の一例です。

認証後の不審な操作を監視する

監視では、サインインの成否だけで判断を終えないことが重要です。Microsoftのトークン窃取対応資料では、サインインログ、監査ログ、Officeの操作、関連端末の情報などを調べるよう案内しています。新しい認証方法や端末の登録、メール転送ルールの追加なども確認対象となります。これらの情報は、必要に応じてSIEMなどへ集約し、関連付けて確認できるようにします。たとえば、普段と異なるサインインと、その後の転送設定変更を、同じアカウントの時系列として調べる運用が考えられます。ただし、不審な出来事が一つあっただけでEvilTokensによる侵害と断定することはできません。利用者の操作や業務上の変更だったかを確認し、侵害の有無と範囲を絞り込む必要があります。

侵害が疑われるアカウントを封じ込める

アカウント侵害が疑われる場合、Microsoftは、侵害が疑われるアカウントを調査中は一時的に無効化することを推奨しています。あわせて、アクティブなセッションと更新トークンを失効させ、登録されたMFAの方法や端末、同意済みアプリ、管理者権限などを点検します。不正なメール転送設定や、通常の画面では見落としやすい受信箱ルールも確認対象です。パスワードを変更して利用者が再びログインできたことだけでは、攻撃者が残した設定まで除去できたとは限りません。どのアクセスを止め、どの変更を戻し、どのログで確認したかを記録し、公式手順に沿って復旧することが必要です。

送金や支払情報の変更は別経路で確認する

EvilTokensでは、侵害した受信箱から取引関係や支払いに関する情報が把握され、なりすましや送金詐欺に悪用される可能性があります。振込先の変更や送金依頼など、金銭に関わる重要な依頼については、メールだけで判断せず、既知の電話番号など信頼できる別の連絡手段で確認することが重要です。

EvilTokensへの対策は、認証管理だけでは完結しません。認証フローの制御、不審な操作を追跡できるログの整備、侵害時の対応、送金依頼の確認までを、自社の担当者と手順に落とし込むことが重要です。正規の認証画面を通った操作であっても、誰のアクセスを許可しようとしているのかを確認する視点が求められます。

【参考情報】

編集責任：木下

アカウント侵害や不正アクセスが疑われる場合は

BBSecでは、セキュリティインシデント発生時の初動対応から、原因・影響範囲の調査、フォレンジック調査、再発防止まで支援しています。

平時の対応体制を見直したい場合

インシデント初動対応準備支援サービスはこちら

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

最新情報はこちら

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

投稿日:

ClosedQuorumとは AIが次の動作を選ぶマルウェアの仕組みと対策

Share
ClosedQuorumとはアイキャッチ画像

生成AIの活用が広がる中、サイバー攻撃でもAIを組み込んだ新たな手法が確認されています。2026年9月、Cisco Talosは、複数のAIモデルに問い合わせながら次の動作を選択するWindows向けマルウェア「ClosedQuorum」の解析結果を公表しました。本記事では、ClosedQuorumの仕組みと現時点で確認されている範囲を整理し、AIを組み込んだマルウェアに対して企業がどのような監視・対策を考えるべきか解説します。

ClosedQuorumとは

ClosedQuorumは、実行中に複数のAIモデルへ問い合わせ、その回答を基に次の動作を選択する仕組みを備えたWindows向けマルウェアです。 Cisco Talosが2026年9月22日に解析結果を公表しました。AIが侵入から目的達成までの全工程を自由に考案するわけではなく、あらかじめ実装された複数の動作から、次に実行するものを選択する設計です。ただし、Talosは報告時点で、ClosedQuorumが実際の攻撃に使用されたことを確認していません。公開配布版には仮のAPIキーなどが含まれており、一連の処理が最後まで動作する様子も観測されていません。本稿では、こうした現時点で確認されている範囲を踏まえ、解析で判明した仕組みと、一般的な防御策から考えられる監視のポイントを分けて説明します。

AIが実行中の判断に加わる仕組み

ClosedQuorumは最大4系統のAIモデルへ順番に問い合わせ、最多票を得た動作を選びます。応答を集計するのはマルウェア側のプログラムです。認証情報や暗号資産ウォレット情報の収集、別プロセスへのコード注入、継続実行のための設定といった実装済みの処理を選択する設計が確認されています。C2は、マルウェアへの指示や制御を指します。今回の特徴は、この動作選択に商用AIのAPIを利用する点にあります。AIが開発時にコード作成を手伝うことと、動作中のソフトウェアがAIの応答を処理に反映することは、区別して捉える必要があります。

図1：Talosの静的解析を基にした設計の概略

出典：Cisco Talos「The Closed Quorum: Inside the first reported autonomous AI C2 implant」（https://blog.talosintelligence.com/the-closed-quorum-inside-the-first-reported-autonomous-ai-c2-implant/）を基に弊社作成
※実際の攻撃での使用と、一連の処理が最後まで動作することは確認されていません。公開配布版には仮のAPIキーなどが含まれています。

AIの痕跡と攻撃の実態を分けて評価する

Talosが同日に紹介した研究ツールCAIRNは、AI向けの指示文やAPIの接続先などの情報を手掛かりに、AIを組み込んだマルウェアを調べるものです。同社は、AI関連の文字列などの痕跡だけでは、実際にはAIを組み込んでいない検体も候補に含まれるため、最終的な判断にはリバースエンジニアリングによる検証が必要だと説明しています。企業がAIマルウェアの情報を読む際も、「AIとの接点がある」「攻撃機能が実装されている」「実際に被害が発生した」という確認の段階を混同しないことが重要です。これはCAIRNの説明を踏まえた情報評価の観点です。検体の解析結果だけで、被害規模や攻撃の成功率まで判断することはできません。

ClosedQuorumを理由に、自律型サイバー攻撃がすでに広く成功していると結論づける根拠はありません。一方で、企業が点検できる項目はあります。以下では、MITRE ATT&CKが整理する既知の攻撃手法と防御策を基に、監視体制の確認方法を考えます。これはClosedQuorum固有の検知性能を保証するものではありません。

正規サービスへの通信は利用の文脈まで確認する

正規のWebサービスを攻撃の制御に使う手口は、MITRE ATT&CKでも整理されています。通信先が著名なサービスであることだけでは、安全性を判断できません。MITREは、通常と異なるプロセスからの外向き通信や、不自然な状況で行われるWeb API呼び出しを、検知の観点として挙げています。この考え方をAIサービスの通信に当てはめると、確認したいのは、どの端末で、どのプログラムが、何の業務のために通信したかです。承認済みアプリによる通常の利用と、用途不明の実行ファイルによる通信を切り分けられるよう、通信情報と端末上の処理を関連付けて確認することが重要です。

通信制御も業務上の必要性を踏まえて設計します。MITREは、許可されていない外部サービスの利用をWebプロキシで制限する対策を挙げています。自社で認めるサービスと利用経路を整理しておけば、不明な通信を調べる際の判断材料になります。

図2：MITRE ATT&CKの一般的な検知観点を基に作成した監視の例

出典：Cisco TalosおよびMITRE ATT&CK（T1102、T1003.001、T1053.005）を基に当社作成
※一般的な検知・監視の考え方を示したものであり、個別の兆候やAIサービスへの通信だけでClosedQuorumへの感染を判断するものではありません。

認証情報へのアクセスと継続実行の設定を監視する

端末側では、認証情報を扱う処理への不審なアクセスが重要な確認対象となります。MITRE ATT&CKは、Windowsの認証処理に関わるLSASSへの異常なアクセスと、その後のメモリダンプやファイル作成を、一連の動作として捉える検知方法を示しています。EDRなどで取得した記録を調べる際も、実行ファイルの名前だけでなく、実際に何へアクセスしたかを確認することが重要です。予防策としては、認証情報の保護、特権アカウントの利用制限、LSASSを保護する設定などが挙げられます。ただし、Credential Guardなどの保護機能にも適用条件と守備範囲があります。導入済みという理由だけで、すべての認証情報窃取を防げると判断しないことが必要です。

継続実行を狙う設定変更にも目を向ける必要があります。たとえば、Windowsのスケジュールタスクは正規の管理用途にも使われますが、攻撃者に悪用されることがあります。MITREは、不審なタスクの作成や変更と、その後の実行を関連付ける検知を示しています。管理作業として説明できるかを確認し、必要以上の権限で動くタスクや不明な実行先を調査することが重要です。

AIという名称より取得できる証拠を確認する

自社の監視体制を点検するなら、通信と端末の記録を結び付けられるかを確認するところから始めることが重要です。SOCや外部の監視担当者とも、不明な外向き通信が見つかったときに、その実行元や前後の処理まで調べられるかをすり合わせておきましょう。ClosedQuorumは、AIを動作選択に使う設計を具体的に示した解析事例です。現時点で確認されている事実を踏まえながら、既存のログ、認証情報の保護、権限管理を点検することが重要です。その積み重ねが、AIを組み込んだマルウェアについても、名称や印象に左右されず調査するための土台になります。

【参考情報】

編集責任：木下

継続的な監視・検知体制の見直しを

サイバー攻撃の手法が変化する中でも、不審な通信や端末上の挙動を継続的に監視し、複数の兆候を関連付けて確認できる体制が重要です。BBSecでは、セキュリティ監視・分析を支援する「G-MDR®」を提供しています。

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

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

最新情報はこちら

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

投稿日:

AIエージェントを悪用したECサイト攻撃 ―カード情報窃取の報告から考える対策

Share
AIエージェントによるECサイト攻撃アイキャッチ画像

AIエージェントを悪用したECサイトへのサイバー攻撃について、Gambit Securityが2026年9月22日に調査結果を公表しました*1。同社は、2社から60万件を超えるカード記録が窃取されたと報告しています。同報告は暫定的な調査結果に基づくものですが、EC事業者が確認したいのは、自社の決済画面が不正に変更されていないか、攻撃の入口を放置していないかという具体的な問題です。

Gambit Securityが報告したAIエージェントの役割

Gambitは攻撃者のステージングサーバーを調べ、脆弱性調査を担うStrix、侵入目標に向けて動くCairn、攻撃全体を調整するHermesの利用を確認したと説明しています。人間も短い指示を出しており、完全な無人攻撃と表現するのは適切ではありません。同社によると、9月10日から15日に105件の攻撃プロジェクトが開始され、少なくとも27社で程度の異なる侵害が発生しました。これらは被害企業による一斉の公式発表ではなく、Gambitの調査結果です。報告には直接確認した証拠のほか、ログやAIの自己報告を組み合わせて評価した情報も含まれ、同社は一部に誤りや不正確さがあり得ると明記しています。

図1：報告されたAIエージェントの役割

出典：Gambit Security「Autonomous AI Agents are breaking into hundreds of Online Retailers for $25 a target in an ongoing campaign」（https://gambit.security/blog-posts/autonomous-ai-agents-online-retailers-25-a-company）をもとに弊社作成。
各ツールの主な役割を簡略化したものであり、すべての対象で同じ順序・攻撃経路が用いられたことを示すものではありません。

カードスキマーは決済画面に何を仕込むのか

今回の調査では、カード情報を盗む不正スクリプトの設置も報告されています。ただし、60万件超というカード記録のすべてが、この仕組みだけで窃取されたという意味ではありません。[1]Web上のカードスキマーとは、決済時に入力されるカード情報などを盗み取るための不正なプログラムを指します。こうしたeスキミングでは、決済ページに不正なスクリプトが組み込まれ、利用者のブラウザー上で入力されたカード情報などが窃取されることがあります。

PCI Security Standards Council（PCI SSC）も、決済ページのスクリプト管理と改ざんの監視を重要な対策として説明しています*2。サイト担当者が決済画面の見た目だけを確認しても、読み込まれるスクリプトの正当性までは判断できません。運用上は、画面の表示確認とは別に、どのスクリプトを、どの目的で、誰の承認に基づいて動かしているのかを把握する必要があります。

図2： Webスキミングの基本的な仕組みと確認箇所

出典：PCI Security Standards Council「Payment Page Security and Preventing E-Skimming」（https://blog.pcisecuritystandards.org/new-information-supplement-payment-page-security-and-preventing-e-skimming）をもとに弊社作成。
一般的なeスキミングの仕組みを簡略化した模式図であり、今回報告されたすべての被害経路を示すものではありません。

決済ページのスクリプトと変更履歴を確認する

PCI SSCの解説は、PCI DSSの要件6.4.3と11.6.1について、決済ページのスクリプトの承認、完全性の確認、改ざん監視に焦点を当てています。スクリプトだけでなく、セキュリティに影響するHTTPヘッダーの変更も確認対象となります。個別の適用範囲や検証責任は、決済構成や契約関係を踏まえてアクワイアラーなどに確認する必要があります。

実務に落とし込むなら、最初に決済ページに関係する変更を誰が把握しているかを確認したいところです。EC担当者、開発会社、決済サービスの担当者が、それぞれ自分の管理部分だけを見ていると、全体の説明ができなくなります。自社で変更できる箇所と、委託先へ確認すべき箇所を整理しておくことが出発点となります。例えば、解析タグの追加を依頼する際に、設置目的と承認者、対象ページを記録します。改ざん検知の通知を受けたら、その時間帯に予定された更新があったかを照合します。通常の変更と不審な変更を確認するための情報を、日常の更新作業から残しておくことが重要です。

侵入経路を調べる診断と改ざんを見つける監視

ECサイトの不正アクセス対策を考える際は、「攻撃が入り込む問題はないか」と「すでに不正な変更が起きていないか」を別々に確認する必要があります。脆弱性診断は主に前者、改ざん検知は主に後者を確認するための取り組みです。片方を実施したというだけで、もう片方の確認が済んだことにはなりません。

診断の対象を相談するときは、商品ページのURLだけを渡すのではなく、ログインや管理機能、APIなど、サイトの機能構成を共有することが重要です。BBSecのSQAT® for Webでは、入出力処理、認証、セッション管理などを診断対象として示し、検出した問題の深刻度と推奨対策を報告しています。監視を導入する際も、通知の受信先を設定するだけで終えず、誰が内容を確認し、誰が開発会社へ連絡するかを決めておく必要があります。営業時間外に通知された場合の連絡先や、決済機能の停止を判断する責任者を定めておけば、発見後の対応を具体化できます。これは今回の個別被害を推測したものではなく、ECサイト運営で準備しておきたい対応体制です。

BBSecの改ざん検知で日々のサイト変更を監視する

BBSecの「Webサイトコンテンツ改ざん検知」は、Webサイトの不正な変更やマルウェアの埋め込みを確認するサービスです。クローリング型のCracker Probing-Eyes® Detectが、設定したURLを起点に定期的にサイトを検査します。またWebサーバーにエージェントを導入するCracker Probing-Eyes® Detect Plusは、ファイルの改変をリアルタイムで監視する方式です。導入を検討する際は、自社の決済ページがどのサーバーから配信され、どこにスクリプトが置かれているかを共有し、監視したい範囲に合う方式を相談することが重要です。

ただし導入しただけですべてのカードスキマーを検知できる、あるいはPCI DSSの関連要件への適合が確定すると判断することはできません。対象環境と監視範囲を確認して設計する必要があります。管理画面のアクセス制御など、基本対策の実施状況から整理したい場合には、「EC加盟店様向け セキュリティ・チェックリスト対応アセスメント」も選択肢となります。対応状況の確認と報告に加え、是正支援を含むコースでは、開発ベンダーとの打ち合わせへの同席などを提供しています。

異常を見つけた後の対応まで準備しておく

不審なスクリプトや予期しないファイル変更が見つかったときは、対象ページ、発見時刻、検知内容を整理し、調査担当者に引き継ぎます。BBSecのデジタルフォレンジックを含む緊急対応支援では、状況把握や証拠保全、原因調査、今後の対応方針について相談できます。

自社サイトを守るために、まずAI攻撃かどうかを判定する必要はありません。公開中の機能に弱点を残していないか、決済ページの変更を把握できているか、異常発見時に動けるかを確かめることが重要です。今回の報告を、自社のECサイトの診断範囲と監視体制を見直す機会にしてはいかがでしょうか。

【参考情報】

編集責任：木下

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

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

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

最新情報はこちら

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

投稿日:

WordPressの脆弱性CVE-2026-87902で攻撃を観測 ―更新と侵害確認のポイント

Share
WordPress CVE-2026-87902の対策アイキャッチ画像

WordPressの脆弱性「CVE-2026-87902」を狙い、PHPファイルの書き込みやコード実行につなげようとする攻撃が観測されています。WordPressは2026年9月22日に修正版7.1.2を公開し、速やかな更新を推奨しています*3。サイト運用者は修正版を適用するとともに、更新前に不正アクセスを受けていなかったか確認することが重要です。

CVE-2026-87902とは何か

CVE-2026-87902は、ページテンプレートの解決処理に存在するパストラバーサルの脆弱性です。認証されていない攻撃者が、利用中のテーマのディレクトリ外にある、読み取り可能なローカルPHPファイルを処理に取り込ませることができます。テーマとサーバー側の条件が重なると、リモートコード実行（RCE）につながる可能性があります。

影響条件には、有効な親テーマまたは子テーマの直下にpage-で始まるディレクトリがあることと、Webサーバーの実行アカウントから読み取り可能な対象PHPファイルが存在することなどが含まれます。公式情報では、PEARに含まれるpearcmd.phpと、PHP設定のregister_argc_argvがOnになっている環境を、RCEに至る経路の一つとして挙げています。[2] したがって、WordPressを使用しているという理由だけで、すべてのサイトで同じようにコード実行が成立するわけではありません。一方で、テーマやPHP環境を確認できていない段階で、自社サイトを影響対象外と判断することも避ける必要があります。

図1：CVE-2026-87902の成立条件と影響

出典：WordPress「GHSA-7hp8-65ch-5whp」（https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-7hp8-65ch-5whp）をもとに作成
※ローカルPHPファイルの読み込みからRCEに至るには追加の条件があり、pearcmd.php経由の例ではregister_argc_argv = Onであることが条件となります。

7.1.1への更新だけでは今回の対策にならない

CVE-2026-87902は、WordPress 7.1系列だけの問題ではありません。公式アドバイザリでは、7.1系列の影響範囲を7.1.0～7.1.1、修正版を7.1.2としています。また、旧系列にも修正版が提供されており、例えば7.0系列は7.0.6、6.9系列は6.9.9で修正されています。利用中のWordPressの系列と、公式アドバイザリに掲載されている修正版の一覧を照合する必要があります*2。更新作業を外部の制作会社や保守会社に任せている場合は、「対応しました」という連絡だけでなく、適用後のバージョンと実施日時も共有してもらうと管理しやすくなります。自動更新を利用しているサイトでも、処理が完了しているかを実際に確認しておきましょう。WordPress公式は、管理画面の更新機能に加え、対応している環境では自動バックグラウンド更新が開始されると案内しています。

観測された攻撃と侵害成功を区別して読む

Patchstackは2026年9月23日の更新で、単なる脆弱性の探索に加えて、pearcmd.phpを介して攻撃者が用意したPHPの内容をファイルへ書き込もうとするリクエストを報告しています*3。観測されたペイロードには、動作確認用の文字列を残すもののほか、アクセス時にシェルコマンドを実行させるものも含まれていました。これは、CVE-2026-87902を狙った実際の悪用活動が行われていることを示す報告です。一方で、Patchstackが観測したリクエストが、そのまますべての対象サイトで侵害に成功したことを意味するわけではありません。自社サイトについては、攻撃リクエストが到達していたか、ファイルが作成されていないか、コードが実行されていないかをそれぞれ確認する必要があります。

調査の手掛かりとして、Patchstackはpagenameに不審なトラバーサル表現を含むリクエストや、pearcmd、config-show、config-createに関係する痕跡、/tmpや/var/tmpに作成された不審なPHPファイルなどを挙げています。これらは、担当者がログやファイルを確認する際の手掛かりです。該当する語句やファイルが存在することだけで侵害を断定することはできません。また、ログの保存期間や取得対象によっては記録そのものが残っていない場合もあるため、該当する痕跡が見つからないことだけで侵害を否定することもできません。

更新と並行して確認したいサイトの状態

サイトに不審な変化が確認された場合は、発見時刻、表示内容、直前に行った運用変更などを記録し、ホスティング事業者や保守会社に連絡します。WordPress公式の侵害対応ガイドでも、状況を記録することやホスティング事業者に確認すること、クリーンアップ前に環境のスナップショットを保存することなどが案内されています*4。原因を調べる前に不審なファイルを一括して削除すると、侵入経路や影響範囲を確認するための情報を失う可能性があります。そのため、不正アクセスが疑われる場合は、修正や削除を進めるだけでなく、必要な記録やデータを保存することも検討します。

実務では、更新を行う担当者と、侵害の有無を確認する担当者を明確にしておくことも重要です。更新によって脆弱な処理を修正できても、すでに追加された不審なファイルや不正なアカウントの有無は別途確認する必要があります。調査によって侵害が判明した場合は、影響範囲を把握したうえで封じ込めを進め、復旧後の認証情報の変更や再発防止策も含めて対応を検討します。

図2：更新と侵害確認を並行して進める対応例

出典：WordPress 7.1.2 Release（https://wordpress.org/news/2026/09/wordpress-7-1-2-release/）および「FAQ My site was hacked」（https://wordpress.org/documentation/article/faq-my-site-was-hacked/）をもとに作成。
※封じ込め・証拠保全・更新の具体的な順序は、被害状況に応じて判断します。

日常のWordPress運用に残したい対策

今回の対応を終えた後は、誰がどのサイトを管理しているか、更新情報を誰が受け取るかまで見直しておきましょう。例えば、コーポレートサイトとは別に運用している採用サイトやキャンペーンサイトについても、同じ管理台帳で確認できるようにしておくと、脆弱性が公表された際に対象サイトを探すところから始めずに済みます。WordPress公式のセキュリティ強化ガイドでは、WordPress本体やサーバ側ソフトウェアを最新の状態に保つこと、アクセスを適切に制限すること、データベースやファイルをバックアップすることなどが案内されています*5。実務では、バックアップを取得しているかだけでなく、復元に必要なデータがそろっているか、復旧を依頼する連絡先が明確になっているかまで確認しておくことが重要です。

侵害が疑われる場合はBBSecの緊急対応支援へ

不審なPHPファイルが見つかった、サイトが改ざんされた、更新前に侵害されていなかったか自社だけでは判断できない、といった場合には、BBSecのデジタルフォレンジックを含む緊急対応支援をご相談いただけます。デジタルフォレンジックは、サーバや端末などに残されたデータを調査し、何が起きたのかを明らかにするための調査です。BBSecでは、インシデント発生時の事象把握、証拠保全・データ収集、原因調査、再発防止に向けた事後対策方針の検討などを支援しています。

緊急コンタクトセンターでは、取引の有無にかかわらず24時間365日相談を受け付けています。相談時には、対象サイト、利用しているWordPressのバージョン、異常を発見した時刻、すでに実施した作業などを整理しておくと、状況を伝えやすくなります。

BBSec緊急コンタクトセンター連絡先電話番号
※外部サイトにリンクします。

平時の対策や復旧後の見直しには、Webアプリケーション・API脆弱性診断「SQAT® for Web」を活用できます。自動ツールによる診断とエンジニアによる手動診断を組み合わせ、攻撃の入口となる可能性のある問題箇所を確認するサービスです。脆弱性診断と、過去の侵害状況を調べるデジタルフォレンジックでは目的が異なります。すでに侵害が疑われている場合は、まず現在の状況や懸念点を伝えたうえで、ブロードバンドセキュリティ（BBSec）までご相談ください。

お問い合わせページリンクボタン

【参考情報】

編集責任：木下

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

最新情報はこちら

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

投稿日:

2026年の国内ランサムウェア被害をCisco Talosが調査 ―バックアップまで狙う攻撃への対策

Share
2026年の国内ランサムウェア被害アイキャッチ画像

ランサムウェア対策では、業務データだけでなく、復旧に必要なバックアップや、その管理権限を守ることも重要です。Cisco Talosは2026年9月17日、日本国内のランサムウェア被害動向と攻撃基盤に関する調査結果を公表しました*6。本記事では、この調査から分かったことを整理し、企業が見直しておきたい監視、アクセス管理、復旧への備えについて解説します。

Talosが把握した国内ランサムウェア被害は90件

図1：日本のランサムウェア被害件数の比較

出典：Cisco Talos「Ransomware incidents in Japan in the first half of 2026」（https://blog.talosintelligence.com/ransomware-incidents-in-japan-in-the-first-half-of-2026/）を基に弊社作成
※日本全体の被害総数ではありません。

Talosが調査で把握した日本のランサムウェア被害は、2026年1～7月に90件でした。前年の同じ期間の86件から4件（約4.7％）増加となります。この90件はTalosが把握した範囲の数値で、日本全体の被害総数を示すものではありません。業種別では製造業が34％を占めました。また、資本金が分かる組織のうち、10億円未満の組織は78％でした*2。

同調査は企業規模を見る参考にはなりますが、資本金だけで中小企業に該当するかを判断することはできません。被害件数の大小だけで自社の安全性を測らず、守るべき業務やデータに照らして対策を点検しましょう。

The Gentlemenの調査で見えたバックアップへの接近

今回、国内で最も多く観測されたグループはThe Gentlemenの14件で、QilinとSafePayが各7件で続きました。TalosはThe Gentlemenに関連するとみられる攻撃者の基盤を調べ、バックアップ内のWindowsファイルシステムを参照し、認証情報やパスワードハッシュを抽出したほか、バックアップデータを外部のクラウドストレージへ転送した痕跡を報告しています。攻撃の流れは操作履歴などから再構成したものであり、すべての被害組織で同じ経路の攻撃が成功したと確認されたわけではありません。

バックアップは、情報の保管先としても点検対象になります。復旧用のコピーに重要な情報が含まれているなら、そのコピーを誰が読めるのか、誰が削除できるのかまで確かめる必要があります。英国NCSCも、バックアップの管理に使うアカウントやアクセス経路の保護、多要素認証の利用を推奨しています*3。取得の成否だけでなく、保存先へのアクセスを制御できているかが確認の要点です。

QilinのAI利用はどこまで分かったのか

Talosがランサムウェア「Qilin」による攻撃を受けた環境を調査したところ、Qilinが使用していたオープンディレクトリから見つかったPythonスクリプトに、AIによる生成を示唆する特徴が確認されました。Talosは、その確度を中～高程度と評価しています。確認されたスクリプトには、Veeamバックアップを停止・無効化・破壊する機能を持つものも含まれていました。ただし、AIが攻撃全体を自律的に実行したと証明されたわけではありません。AI利用に関する評価と、スクリプトが備える機能は分けて読む必要があります。

企業の対策として点検したいのは、強い権限を持つアカウントで、どの操作まで実行できるかです。管理者権限の付与範囲を絞り、操作を記録し、不審な動きに対応する体制を整えましょう。こうした基本対策は、攻撃用コードの作成方法にかかわらず必要になります。AIという話題だけに対策を寄せず、自社で管理できる権限と監視の範囲を確認しましょう。

【関連記事】
Cisco Secure Firewall Management Center（FMC）の脆弱性を悪用し、侵入後にQilinランサムウェアが展開された事例も確認されています。実際の攻撃で確認された活動や、対象製品の確認、修正版へのアップグレードと侵害調査のポイントについて解説しています。
「Cisco FMCの脆弱性が実悪用―Qilinランサムウェアへの悪用事例と対策」

企業が見直したいランサムウェア対策

ここからは、警察庁と英国NCSCの対策情報をもとに、自社で確認する際の観点を整理します。

図2：侵入の防止から被害調査までの対策範囲

参考：警察庁「ランサムウェア被害防止対策」（https://www.npa.go.jp/bureau/cyber/countermeasures/ransom.html）、National Cyber Security Centre (NCSC)「Mitigating malware and ransomware attacks」（https://www.ncsc.gov.uk/guidance/mitigating-malware-and-ransomware-attacks）を基に弊社作成
※ランサムウェア対策として、公開機器・リモート接続、端末・管理アカウント、重要サーバー・バックアップを保護し、インシデント発生時には証拠保全、影響調査、復旧判断を行う流れを示した模式図。
※一般的な対策の位置関係を示しており、今回の調査で確認された攻撃をそのまま再現した図ではありません。

公開機器とリモート接続の管理を確かめる

VPNなど外部から接続する機器は、使用製品とバージョン、更新を担当する部署を把握し、修正プログラムを適用できる状態にしておきましょう。認証には多要素認証を組み合わせ、接続元やアクセス先も必要な範囲に制限します。警察庁は、脆弱性への対応に加えて認証情報の管理と権限の最小化を案内しています。担当者が確認する際は、設定の有無とあわせて、例外として残された接続がないかも点検しましょう。

端末と認証のログをつなぎ 初動対応を決める

侵入後の横展開とは、攻撃者が侵害した端末などを足掛かりに、別のシステムへアクセスを広げることです。その調査や検知には、端末内の活動だけでなく、認証やネットワーク通信の記録も役立ちます。NCSCは、端末、サービス、ネットワーク機器など複数の情報源を組み合わせた監視を勧めています*4。

運用の点検では、不審なログインが見つかった際に、その前後の端末操作や外部通信を調べられるかを確認します。さらに、夜間に通知を受け取る担当者や、アカウント停止・端末隔離を判断する担当者を決めておきましょう。セキュリティ製品を導入するだけでなく、異常を検知した際に実際の調査や対応へ移れる体制になっているかを確認することが重要です。

バックアップを保護し復元できることを試す

バックアップは、業務環境が侵害されても一緒に失われないよう保管する必要があります。NCSCは、ネットワークから分離したバックアップ、復元手順の定期的な確認、バックアップ製品の更新に加え、インシデントを想定した対応計画の策定や訓練を推奨しています*5。クラウドに保存する場合も、過去の世代を直ちに削除されない仕組みがあるかを確認しましょう。復旧の準備では、どの業務を先に再開するかを決め、そのために必要なシステムを実際に戻せるか試します。バックアップ取得の記録が残っていても、担当者が復元手順を実行できるとは限りません。社内システムが使えない状況でも、連絡先や手順書を参照できるようにしておきましょう。

自社の課題に合わせてBBSecの支援を活用する

監視の通知を受け取った後の分析や対応を自社だけで担いきれない場合は、BBSecの「G-MDR®」が選択肢になります。各種セキュリティ対策を統合的に監視・相関分析し、脅威の検知から遮断・封じ込め、被害調査、対応支援を24時間365日体制で提供するサービスです。相談に当たっては、自社で収集できるログや管理対象を整理し、必要な対応範囲を確認するとよいでしょう。復旧計画を見直したい企業には、「ランサムウェアに対応したIT-BCP策定支援」があります。現状の対策状況を調査し、復旧の優先度や目標とする対策レベル、システム・ネットワークと運用の要件、改善計画の策定を支援します。復旧の優先順位と事業再開に向けた要件を具体化したい場合に、検討できるサービスです。

すでに不正アクセスが発生している、または侵害が疑われる場合には、まず侵入経路や影響範囲、情報漏えいの有無などを確認する必要があります。BBSecでは「緊急対応支援」を通じて、初動対応やデジタルフォレンジック、原因・影響範囲の調査、復旧に向けた対応などを支援しています。

また、情報が外部に持ち出された可能性がある場合には、「サイバー脅威情報調査」を組み合わせることで、ダークWeb上で自社に関連する情報が公開されていないかを調査できます。社内のログや端末などを対象とした調査とは目的が異なるため、必要に応じて組み合わせることで、内部の侵害状況と外部への情報流出の両面から確認できます。なお、ダークWeb上で情報が確認されなかったことだけをもって、情報漏えいがなかったと判断することはできません。情報漏えいの懸念がある場合、監視や復旧の備えについても、自社で対応に不安が残る箇所を整理したうえでBBSecへご相談ください。

【参考情報】

編集責任：木下

ランサムウェア対策やインシデント対応についてご相談ください

ランサムウェア対策は、侵入を防ぐだけでなく、監視や初動対応、バックアップからの復旧まで含めて備えることが重要です。自社の対策状況や対応体制に不安がある場合は、ブロードバンドセキュリティ（BBSec）へご相談ください。

お問い合わせページリンクボタン

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

最新情報はこちら

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

投稿日:

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

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

デジタル庁は2026年9月11日、ガバメントソリューションサービス（GSS）への不正アクセスにより、職員や業務関係者の個人情報約24.6万件が漏洩した可能性があると公表しました*6。今回の事案では、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に戻る