Joshinが不正アクセスで一部サービスを停止｜遮断と復旧をどう切り分けるか

株式会社Joshinは、第三者によるネットワークへの不正アクセスの影響で、一部サービスを提供できない状態になったと公表しました。10月16日に不正アクセスを認識し、外部からのアクセスを制限するなどの対応を取った結果として、サービスへの影響が出ていると説明しています。

本稿は2026年10月20日に公式資料を確認したものです。公式ニュース一覧には17日の告知と19日の適時開示が掲載されています。19日の資料を20日に起きた新たな侵害として扱いません。情報流出の有無や詳細な原因は調査中であり、以下のWeb運用例はJoshin内部の構成や実際の復旧方法を示すものではありません。

出典：Joshin：不正アクセスによるシステム障害発生のお詫びとお知らせ（10月19日）

公表資料で確認できることと残る不確実性

10月19日の資料では、外部の専門機関と連携して原因や影響範囲を調べ、個人情報などの流出の有無を確認しているとしています。漏えいの可能性を否定できないことから個人情報保護委員会へ第一報を入れ、判明した場合は速やかに報告すると説明しています。

これを「個人情報の流出が確認された」と言い換えることはできません。参照した資料は、攻撃者、侵入に使われた脆弱性、ランサムウェアの有無、復旧の確定日を示していません。対象のサービス名や停止範囲も、この記事では資料にないものを推測して並べません。

事件を読む側は、サービスが止まっているという利用者への影響と、情報が持ち出されたかという調査結果を分けます。事業者の対応を評価するときも、停止時間だけから封じ込めの適否を断定するのではなく、確認できる範囲と未公表の範囲を区別する必要があります。

出典：Joshin：不正アクセスによるシステム障害発生のお詫びとお知らせ（10月19日）

防御のための遮断もサービス停止を起こす

Webサービスでは、公開画面の背後に認証、在庫、顧客管理、メール、配送などの処理があります。侵害が疑われる接続を切った結果、直接攻撃されていない機能まで動かなくなることがあります。今回の公式資料も、アクセス制限などの対策と一部サービスの停止を関連付けて説明しています。

自社の対応計画では、止める接続と影響する機能を対応させます。たとえば管理ネットワークからの接続を切ると、商品更新だけが止まるのか、注文照会もできなくなるのかを事前に確認します。全体を一括停止する手段に加え、機能単位で受付を制限する方法があるかを検討します。

ただし、影響を小さく見せるために、侵害が疑われる経路を残してよいという意味ではありません。継続できると判断した機能には、依存する認証やデータが信頼できる根拠が必要です。画面が表示されるだけで受付を続けるのではなく、処理結果を安全に記録できるかで判断してください。

出典：Joshin：不正アクセスによるシステム障害発生のお詫びとお知らせ（10月19日）

Web運営では受付済みの処理を先に把握する

以下はECサイトを想定した本サイトの提案です。停止時点の注文を、受付前、受付済み、決済確認中、出荷指示済みなどの状態で確認できるようにします。実際にJoshinで注文や決済にどのような影響があったかを述べるものではありません。自社の障害手順へ落とし込むための仮想例です。

利用者が完了画面を見られなかった場合でも、サーバー側では受付が済んでいることがあります。再送を一律に促すと重複注文につながるため、注文番号や処理識別子で確認できる代替経路を設けます。決済事業者と内部データの照合が終わるまで、自動で再請求しないなどの扱いも先に決めます。

作業には、利用者が見た結果と内部の状態を対応させる記録が必要です。担当者が個人の表計算ファイルへ会員情報を大量に書き出す方法は避け、必要な識別子と処理状態を使って照合します。停止中の暫定運用も、復旧後に正式な記録へ戻せる形式にしておくことが大切です。

独立したお知らせを用意する

自社サイトで会員ログインができない状況でも、利用者が障害の有無と正規の問い合わせ先を確認できる場所は必要です。案内ページが同じ認証基盤や管理ネットワークに依存すると、サービスと一緒に更新できなくなることがあります。障害用の公開先と更新権限を、平常時に確認することを提案します。

案内は、利用できない機能、利用者が今行うこと、行わなくてよいこと、次の案内を出す予定に分けます。確定していない復旧日時を約束する代わりに、調査状況をどの場所で更新するかを示します。公表時刻と更新時刻を残せば、古い情報が転送されても判断しやすくなります。

独立させた案内先にも、管理者の認証やドメイン管理は必要です。緊急用だからと共有パスワードを広く配らず、更新担当と代行担当を決めます。利用者が偽のお知らせへ誘導されないよう、平常時の公式サイトから正規の案内先を示しておく方法も検討できます。

証拠の保全と復旧作業を同時に設計する

NISTのインシデント対応資料は、検知、対応、復旧を組織のリスク管理へ組み込む考え方を示しています。自社の実施案では、最初に確認した現象と時刻、実施した遮断、変更した設定、担当者を同じ対応記録へ残します。調査を終えてから記憶を頼りに時系列を作る方法では、判断の根拠が抜けやすくなります。

証拠を保全する必要がある端末やサーバーを、手当たり次第に初期化したり再起動したりしないようにします。ただし、保全のために被害拡大を許してよいわけではありません。封じ込めと取得すべき記録の優先順位を、対応責任者と専門担当が決める運用を用意してください。

記録の保全先にも権限管理を適用します。共有フォルダーへ全員が上書きできる状態では、後から変更の有無を判断しにくくなります。取得元、取得時刻、実施者、保存場所を対応させ、解析用の複製と原本の扱いを分けることを勧めます。

出典：NIST：SP 800-61 Rev. 3 インシデント対応の推奨事項

ログを増やす際に秘密まで集めない

調査時には、認証結果、管理操作、データ参照、外部通信などの記録が役立ちます。ただし、必要なのは操作を追えることであり、パスワードやトークンの内容を残すことではありません。OWASPのログ管理資料も、認証情報や重要な秘密、機微なデータを直接記録しないよう注意しています。

本サイトが提案する対応票では、記録が存在する期間と、確認できない期間を分けます。ログに不審な操作が見えなかった場合も、必要な種類の記録が残っていなければ、不正操作がなかったと結論付けられません。検索条件、対象期間、時刻の基準を残すと、後続調査で説明できます。

また、遮断の前後でログの収集経路が変わっていないかを確認します。ネットワークを切ったことで中央の監視先へ届かなくなる場合、手元に残る記録の保全が必要です。収集が止まった状態を「新たな攻撃がない」と読み違えないようにしてください。

出典：OWASP：Logging Cheat Sheet

段階的な再開には機能ごとの条件を置く

復旧判断は、トップページが表示されたかだけではできません。自社サービスの再開条件として、侵入経路への対処、必要な認証情報の更新、利用するデータの確認、監視の復帰、受付後の処理が一貫して完了することなどを分けて定義します。これは一般的な実施案で、Joshinの再開基準を代弁するものではありません。

たとえば商品情報の閲覧を先に再開する場合、更新や会員操作を受け付けない状態でも問題がないかを確認します。次に会員機能を戻すなら、認証、照会、通知が意図した接続先へ届くことを検証します。すべてを一度に戻すより、どの段階で異常が生じたかを判断しやすくなります。

再開の承認者、必要な確認結果、異常時に戻す状態もあらかじめ決めます。復旧作業を担当した人だけで安全を判断するのが難しい場合は、別の担当が条件を照合します。緊急の例外を設けるなら、残る制約と責任者を明示し、後で解消したか追える状態にします。

再開直後の確認と利用者への説明

再開後は、技術的なエラーだけでなく、受付件数と処理完了件数の差、通知の重複、古いデータ表示なども監視します。停止前から滞留していた処理が一斉に再開する場合、新規の操作と混ざって通常の状態に見えることがあります。時系列と識別子を使って区別してください。

利用者へは、再開した機能と、まだ制限が残る機能を分けて案内します。サービスが戻ったことを、情報流出の調査完了と同義にしないことも重要です。調査で新しい事実が判明した場合は、前の案内を消して置き換えるだけでなく、変更点が分かるように更新します。

問い合わせ窓口では、未確認の被害を担当者が個別に断定しないよう説明を統一します。不審な連絡への注意喚起と、実際に確認した影響を分けることで、必要な行動を利用者へ伝えやすくなります。

少人数チームでも決めておきたい役割

小さなWeb運営チームでも、通信を止める判断、公開案内、顧客対応、記録の管理をすべて一人が同時に担うと確認が抜けやすくなります。人数を増やせない場合は、役割と実施時刻を分け、重要な変更だけは別の人へ短く確認してもらう方法があります。

平常時に、一時停止できる機能、連絡先、ログの保存期間、緊急用の公開先を確認します。訓練では、本番の通信を切る必要はなく、架空の障害を使って誰がどの順序で判断するかを机上で試せます。そこで分からなかった契約者や管理者を台帳へ戻すことが、実際の対応時間を短くする準備になります。

現在の公表を越えて断定しない

今回確認したJoshinの資料では、詳細な影響と情報流出の有無は調査中です。新しい資料が出るまでは、漏えい確定、特定の攻撃手法、復旧完了などの結論を足さずに参照してください。利用するサービスの最新状況は、同社の正規の案内で確認する必要があります。

Web運営者にとっての実務的な論点は、侵害を止める操作が利用者へ与える影響を把握し、停止中にも案内と記録を維持できることです。封じ込め、調査、再開の判断を分けて準備すれば、焦って接続を戻すことも、根拠なく停止を続けることも避けやすくなります。