--- title: "講談社の個人情報流出3,812件｜フィッシング起点のアカウント侵害の技術解説" url: "https://www.issoh.co.jp/tech/details/16099/" published: 2026-08-03 updated: 2026-10-09 categories: ["脆弱性・インシデント"] publisher: "株式会社一創" --- # 講談社の個人情報流出3,812件｜フィッシング起点のアカウント侵害の技術解説 講談社は2026年8月3日、社用の電子メールアカウントが外部の第三者による不正アクセスを受け、連絡先情報が最大3,812件流出したと公表しました。発端は取引先を偽装したフィッシングメールです。社員がリンクを開き、表示された偽のログイン画面へ認証情報を入力したところ、そのままメールアカウントに不正ログインされました。 報道各社は事実関係を短く伝えていますが、開発と情報システムの現場が知りたいのは別の点でしょう。認証情報を入力してから不正ログインが成立するまでの間に、なぜ何も止められなかったのか。本記事では[講談社の公表文（PDF）](https://www.kodansha.co.jp/notices/723)で確定した事実を整理したうえで、中間者型フィッシングの構造、フィッシング耐性のある認証への移行判断、検知と自動遮断の設計、乗っ取り後の二次拡散対策までを実装者向けに扱います。 ## まとめ：講談社の個人情報流出で確定した事実と実装側で取るべき手 - **事案と規模**：2026年8月3日公表。社用メールアカウント1つが侵害され、連絡先情報は最大3,812件。うち553件のメールアドレス宛に、当該社員を装ったフィッシングメールが大量送信されました。 - **流出項目**：メールアドレスと一部の方の氏名。単体では機微性が低い一方、送信元が実在の担当者であるため次の標的型攻撃の材料としては強く働きます。 - **技術的な本質**：サーバーを掌握された事案でも、認可ロジックが抜けた事案でもありません。正規の認証情報を攻撃者が握り、正規の利用者として振る舞った型です。 - **認証の論点**：偽のログイン画面を中継させる中間者型では、ワンタイムコード方式の二段階認証は突破されます。止めるにはオリジンに結び付いたFIDO2やパスキーが要ります。 - **検知の空白**：7月27日の侵害成立から7月30日の発覚まで3日。気づく契機になったのは大量送信という騒がしい挙動でした。静かな段階で捕まえる監視項目を別に置く必要があります。 - **失効の手順**：講談社の対応にはパスワード変更とセッション削除の両方が明記されています。トークンを握られた前提ではこの2つを必ず対にしてください。 - **二次拡散**：正規アカウントからの送信にSPF・DKIM・DMARCは働きません。送信レートのしきい値と外部への即時通知が実質的な歯止めになります。 - **判断**：全社のパスキー移行を今日決める必要はありません。外部と大量にメールをやり取りする部門から先に倒し、他部門は二段階認証の方式変更で凌ぐ順序が現実的です。 ## 公表文で確定した経緯と流出範囲｜7月27日から8月3日までの動き まず一次情報だけで事実を固めます。出典は講談社が2026年8月3日に公開した[「不正アクセスによる個人情報流出のお詫びとお知らせ」（PDF）](https://www.kodansha.co.jp/notices/723)です。ここを推測と混ぜると、自社に関係のない対策まで抱え込むことになります。2026年10月2日時点で、講談社のお知らせ一覧に本件の続報（原因調査の結果など）は掲載されていません。 | 日付 | 発表主体・出来事 | 内容 | | ---------- | ------------ | --------------------- | | 2026年7月27日 | 社員がフィッシングに遭遇 | 偽ログイン画面へ入力し不正ログイン | | 2026年7月30日 | 攻撃者の窃取と送信、発覚 | 連絡先最大3,812件窃取、553件へ送信 | | 2026年7月30日 | 当該社員が対応 | パスワード変更とセッション削除 | | 2026年7月31日 | 講談社が本人へ通知 | 概要・項目・窓口をメールで通知 | | 2026年8月3日 | 講談社が公表（最新） | 委員会への報告完了も明記 | ### 偽ログイン画面への認証情報入力から不正ログインまでが同日に成立した経緯 公表文によれば、7月27日に社員が取引先を偽装したフィッシングメールのリンクをクリックし、表示された偽のログイン画面で認証情報を入力しました。その結果、当該社員が使用しているメールアカウントへ不正ログインされています。入力と侵害が同じ日付に並んでいる点を見落とさないでください。 認証情報が渡ってから悪用されるまでの猶予は、実務で想定されているほど長くありません。パスワードの定期変更はこの時間軸に間に合わない対策です。入力させない設計にするか、入力されても使えない資格情報にするか、そのどちらかで防ぐ必要があります。 ### 最大3,812件の連絡先情報と553件へのなりすまし送信という被害の二層構造 7月30日、攻撃者は社用メールにログインし、連絡先情報を最大3,812件窃取したうえで、そのうち553件のメールアドレス宛に当該社員を装ったフィッシングメールを大量送信しました。同日、社員が異常に気づき、ログインパスワードの変更とセッションの削除を実施。それ以後の不正アクセスは確認されていないと公表されています。 被害はここで二層に分かれます。第1層は連絡先情報そのものの流出、第2層はその連絡先へ実在の担当者名義で送られたフィッシングメールです。危険度は第2層のほうが高い。受け取った側には、日頃やり取りしている担当者から届いた本物のメールに見えるためです。乗っ取られた社員のアカウントから取材先へ約9,000件が送られ、受け取った日経BPでも認証情報が取られた連鎖は[日経の不正アクセスとなりすましメール約9,000件](https://www.issoh.co.jp/tech/details/18189/)で、Microsoft 365とGoogle Workspaceの調査手順とあわせて扱っています。[標的型攻撃](https://www.issoh.co.jp/column/details/13433/)の成功率は送信元の信頼度でほぼ決まります。 ### 流出項目がメールアドレスと氏名にとどまることをどう評価すべきか 流出した項目は、メールアドレスと一部の方の氏名です。クレジットカード情報や認証情報そのものは含まれていません。件数も3,812件と、大規模流出の部類には入らない規模です。 ただし「軽微」と結論づけるのは早計でしょう。不正の目的をもって行われたおそれがある行為による漏えいは、件数にかかわらず個人情報保護委員会への報告対象です。技術的に見ても、これは1アカウントの侵害で止まった結果に過ぎません。同じ認証情報でクラウドストレージや業務システムへ横移動されていれば、被害の桁は変わっていました。 ## 認可不備でもホスト侵害でもない「正規アカウントの乗っ取り」という型 同じ情報漏えいでも、攻撃レイヤが違えば打ち手は入れ替わります。ここを揃えずに対策を横展開すると、今回の型は素通りします。 ### 認証情報が渡った時点で防御の主戦場がどこへ移るかを判断する視点 攻撃者が正規の認証情報を持ってログインしている以上、アプリケーション側の防御はほぼ機能しません。入力値の検証も所有者チェックも権限判定も、すべて「本人である」という前提の上で正しく動きます。攻撃者はその前提を買い取った状態にあります。 主戦場は3か所へ移ります。認証そのものを詐取されない方式へ変えること、認証に成功した後の振る舞いを見て遮断すること、侵害成立後の被害拡大を止めること。以降の章はこの3つに対応しています。 ### 直近3事案と本件を並べたときに打ち手が入れ替わる理由と切り分け 国内の直近事案と並べると輪郭がはっきりします。[生命保険協会の契約照会システムの事案](https://www.issoh.co.jp/tech/details/15878/)は、2026年9月14日の[調査結果](https://www.seiho.or.jp/info/news/shared/mt-item/20260914.pdf)で、ログインしていないゲストユーザーに他の利用者の個人情報を参照できる権限が誤って付与されていた設定不備と確定しました。打ち手は未認証プロファイルの権限設定の点検です。[タカラトミーのデュエマアプリの事案](https://www.issoh.co.jp/tech/details/15978/)は「ユーザー認証機能の設計・実装の脆弱性」と公表されただけで、認可の抜けか認証の欠陥かは明らかにされていません。どちらも「誰に何を見せてよいか」の判定や設定の側に穴があった型です。 同時期に起きた[ショップサーブの情報漏えい](https://www.issoh.co.jp/tech/details/16098/)はさらに別で、サーバー上で不正なプログラムが実行され、データが外部へ送信された型です。こちらの打ち手は挙動監視と出口通信の統制でした。本件はそのいずれでもありません。人が資格情報を渡してしまった結果、正規の経路で正規に侵入された状態です。同じ出版社でも入口が異なる事例として、CMSの設定不備からAPI認証情報を狙われ特権アカウントを作られた[集英社の不正アクセス](https://www.issoh.co.jp/tech/details/18197/)があります。4事案を「情報漏えい」で一括りにして同じ再発防止策を配ると、少なくとも3つは的を外します。次の表で分担を整理します。 | 事案の型 | 抜けた層 | 本件との違い | 主な打ち手 | | ----------- | --------- | ------------ | ---------- | | 権限設定の不備 | 未認証ゲストの権限 | ログイン自体が不要 | 未認証権限の点検 | | アプリの認証機能の不備 | 型は非公表 | 正規の資格情報を使わない | 認証と所有者の再検証 | | サーバー侵害 | ホストの実行統制 | アプリを迂回される | EDRと出口監視 | | アカウント乗っ取り | 認証方式と事後検知 | 本件がこの型 | 耐フィッシング認証 | 自社のどのシステムがどの型に近いかを先に切り分けてから、投資先を決めてください。 ## 二段階認証では止まらない領域｜中間者型フィッシングと耐フィッシング認証 今回の公表文には、当該アカウントで多要素認証が有効だったかどうかの記載がありません。断定は避けますが、実装者として押さえておくべきは「有効でも同じ結末になり得る」という点です。 ### 偽ログイン画面が中間者として振る舞うとワンタイムコードは無効化される 攻撃者が用意する偽のログイン画面は、単なる入力フォームとは限りません。入力された値を本物のサービスへその場で転送し、返ってきた画面をそのまま利用者へ見せる中継役として動きます。この方式では、利用者が入力したワンタイムコードも即座に本物へ渡され、成立したセッションのトークンが攻撃者側に残ります。 結果として、SMSや認証アプリのコードを使う[二段階認証](https://www.issoh.co.jp/column/details/13268/)は、中継の前では時間稼ぎにしかなりません。プッシュ通知の承認方式も同様です。[多要素認証の方式差](https://www.issoh.co.jp/tech/details/13314/)は、要素の数ではなく詐取耐性で評価してください。 ### FIDO2とパスキーがオリジン結合で偽サイトへの資格情報送出を成立させない仕組み 止められる方式は現状ほぼ1つです。[FIDO2やパスキー](https://www.issoh.co.jp/tech/details/1440/)のように、資格情報がドメイン（オリジン）と結び付いた方式へ切り替えること。認証器は要求元のオリジンが登録時と一致しない限り署名を返しません。この仕組みはW3Cの[Web Authentication仕様（Level 3）](https://www.w3.org/TR/webauthn-3/)で定められており、パスキーの位置づけは[FIDO Allianceのパスキー解説](https://fidoalliance.org/passkeys/)で確認できます。偽のログイン画面がどれだけ本物そっくりでも、ドメインが異なる時点で認証が成立しない構造です。 実装面の論点は、ブラウザ側のAPIとサーバー側の検証をどう組むかです。登録と認証のフロー、チャレンジの検証、認証器の属性判定といった要点は[WebAuthnの実装解説](https://www.issoh.co.jp/tech/details/15375/)に整理しています。自社開発のシステムへ後付けする場合、既存のパスワード認証と並走する期間の設計が本体より手間取ります。 ### 全社移行が終わるまでの期間に効く暫定策とフォールバック経路の閉じ方 移行には時間がかかります。その間に効く手を順に挙げます。 1. 認証アプリのコード入力方式を、端末証明書やハードウェアキーを使う方式へ置き換える 2. フォールバック経路を閉じる。設定済みの利用者にパスワードとコードでのログインを許可したままにしない 3. アカウント回復の窓口を絞る。ヘルプデスク経由のリセットは耐フィッシング認証を迂回する最短経路です 4. 取引先とやり取りする部門から先に移行する。偽装しやすい相手を多く持つ部門ほど優先度が上がります 2番目を軽く見ないでください。強い認証を追加しても、弱い経路を残せば攻撃者はそちらを通ります。移行の成否は、新方式を配った数ではなく旧方式を閉じた数で測るべきです。[認証・ID管理の全体設計](https://www.issoh.co.jp/column/details/13631/)では、この経路の棚卸しが最初の工程にあたります。 ## 3日間気づけなかった状態を短縮する検知と自動遮断の設計と運用基準 7月27日に侵害が成立し、発覚は7月30日でした。この3日を縮める設計を考えます。 ### 不審サインインの判定材料と条件付きアクセスで遮断する条件の置き方 ログインの成否だけを見ていても、この型は捕まりません。見るべきは、成功したログインが平常とどう異なるかです。判定材料は、接続元のIPアドレスと地理情報、端末の識別子、平常時の接続時間帯、直前のログインからの移動距離、接続元ネットワークの種別になります。 これらを条件付きアクセスの規則として書き、条件から外れたセッションは追加認証を要求するか、その場で遮断します。設計時の勘所は、遮断の対象をログイン時点に限定しないことです。中間者型ではセッション確立後にトークンだけが持ち出されるため、継続中も定期的に条件を再評価する設定にしておかないと、初回の判定を通過した後は素通りになります。 ### 大量送信という騒がしい挙動に頼らず早期に気づくための監視項目 今回、発覚の契機は大量送信でした。攻撃者が最後に取った最も騒がしい行動です。それ以前の静かな段階では何も鳴っていません。ここで鳴らすには、次の項目を監視対象へ入れてください。 - メールボックスの転送規則や自動振り分け規則の作成・変更（攻撃者が痕跡を隠す定番の手順） - 連絡先やアドレス帳の一括エクスポート、および短時間での大量参照 - 普段使われていないクライアントやプロトコルからの接続 - 同一アカウントに対する、地理的に離れた場所からの連続したアクセス成功 - アプリケーションパスワードやAPIトークンの新規発行 単体では誤検知も出るため、ログを集約して相関させる基盤が前提になります。自社で当番体制を組むか外部に預けるかの判断材料は[SOCの内製とアウトソースの比較](https://www.issoh.co.jp/tech/details/13310/)にまとめています。 ### パスワード変更とセッション削除を対にする失効手順の設計と確認基準 講談社の対応には、ログインパスワードの変更に加えてセッションの削除が明記されています。この2つが対になっている点は、実務として正しい手順です。 中間者型で持ち出されるのはパスワードだけではありません。認証後に発行されたセッショントークンやリフレッシュトークンも攻撃者側に残ります。侵害を疑った時点の手順書には、パスワード変更、全セッションの失効、リフレッシュトークンの取り消し、アプリケーションパスワードの棚卸しと削除、多要素認証の再登録までを1セットで書いてください。ここが分かれていると、対応した気になって侵害が続きます。 講談社は社用メールの基盤を公表していません。以下は、社用メールがMicrosoft 365（Exchange Online・Microsoft Entra ID）の場合の例です。管理者権限を持つアカウントで、Windows PowerShellまたはPowerShell 7から実行してください。1つ目は[Microsoft Graphのサインインセッション取り消し](https://learn.microsoft.com/ja-jp/graph/api/user-revokesigninsessions?view=graph-rest-1.0)で、発行済みの更新トークンとブラウザーのセッションCookieを無効にします。2つ目は[Get-InboxRule](https://learn.microsoft.com/ja-jp/powershell/module/exchangepowershell/get-inboxrule?view=exchange-ps)で、攻撃者が仕込みやすい転送・削除の受信トレイルールが残っていないかを確かめます。 ``` # 事前に Install-Module Microsoft.Graph.Users.Actions, ExchangeOnlineManagement を済ませておく # 1) 侵害が疑われる利用者のサインインセッションを取り消す（更新トークンを無効化） Connect-MgGraph -Scopes "User.RevokeSessions.All" Revoke-MgUserSignInSession -UserId "user@example.co.jp" # 2) 非表示のものも含めて受信トレイルールを一覧し、身に覚えのない転送・削除ルールを探す Connect-ExchangeOnline Get-InboxRule -Mailbox "user@example.co.jp" -IncludeHidden | Select-Object Name, Enabled, Description ``` 取り消しは反映まで数分かかる場合があるとMicrosoftのドキュメントに記載されています。パスワード変更と取り消しの順序は、先にパスワードを変えてから取り消すほうが、攻撃者が古いパスワードで再ログインする隙を残しません。ルールの一覧に見覚えのないものがあっても、削除する前に画面の写しと出力を保存してください。後の調査と報告の材料になります。 ## 乗っ取り後の二次拡散を止める｜DMARCが効かない領域の手当て 本件で実害が広がったのは、連絡先情報の流出そのものより、そこへ送られた553件のフィッシングメールでした。 ### 正規アカウントからの送信にSPF・DKIM・DMARCが働かない理由 なりすまし対策としてのメール認証は、送信ドメインを詐称する攻撃を前提にしています。[DMARC](https://www.issoh.co.jp/column/details/3287/)はSPFとDKIMの検証結果を送信元ドメインと突き合わせ、一致しないメールの扱いを受信側に指示する仕組みです。詐称メールを弾く効果は確かにあります。 ところが本件で送られたメールは、正規のアカウントから正規のメールサーバーを経由しています。SPFもDKIMも通り、DMARCの判定も通過します。[DMARC強化の流れ](https://www.issoh.co.jp/tech/details/12369/)は業界全体として進んでいますが、アカウント乗っ取り型の送信はその守備範囲の外側にあると理解してください。混同すると、rejectにしたから安心という誤った結論に至ります。 ### 送信レートのしきい値と外部への通知を歯止めにする段取りと監視体制 メール認証で止まらない以上、歯止めは送信側の統制に置きます。実装として置けるのは次の3つです。 第1に、1アカウントあたりの単位時間内の送信数と宛先数にしきい値を設け、超過時は保留して管理者へ通知する。553件は通常の業務利用でまず発生しない値です。第2に、宛先ドメイン数の急増を併せて見る。多数のドメインへ短時間に散らす形には攻撃側の特徴が出ます。第3に、送信済みアイテムの削除操作を監視する。攻撃者は履歴を消して発覚を遅らせます。 そのうえで、送信されてしまった後の段取りを事前に決めておいてください。講談社は7月31日付で、流出した可能性のあるアドレス宛に本件の概要と対応窓口を通知しています。発覚の翌日です。この速さは、文面を事故後に書き始めていては出ません。通知テンプレートと承認ルートの事前準備が、二次被害を抑える現実的な手当てになります。[フィッシングの手口と組織的対策](https://www.issoh.co.jp/column/details/13262/)も社内教育の材料にしてください。 ## 報告義務と公表の段取り｜個人情報保護法で問われる期限と起算点 技術対応と並行して走るのが法対応です。順番を誤ると、後から範囲を確定できなくなります。 ### 件数にかかわらず報告対象となる類型と速報・確報の期限を整理する基準 個人情報保護法では、個人データの漏えい等が発生した場合、個人情報保護委員会への報告と本人への通知が義務づけられています（[委員会の漏えい等報告ページ](https://www.ppc.go.jp/personalinfo/legal/leakAction/)）。報告対象の類型のうち、不正の目的をもって行われたおそれがある行為によるものは件数の多寡を問いません。今回のような不正アクセスは、数件であっても報告対象になります。 期限は、速報が発覚日から3〜5日以内、確報は発覚日から30日以内ですが、不正の目的で行われたおそれがある場合は60日以内となります（2026年10月2日時点の同ページの記載）。講談社は7月30日に異常を検知し、7月31日に本人通知、8月3日に公表という流れで、報告完了を明記しています。制度面の変更点は[個人情報保護法改正の解説](https://www.issoh.co.jp/column/details/13787/)で追ってください。 ### 取引先として通知を受け取った側が72時間で確認すべきことの判断基準 本件で通知を受けたのは、講談社の社員と連絡先を交換していた取引先や関係者です。受け取った側の実務を整理します。 - 7月30日前後に当該担当者名義で届いたメールを洗い出し、リンクを開いた利用者を確認する - 開いた利用者がいれば、その端末のログインパスワードを変更し、全セッションを失効させる - 同時期の「口座変更」「請求書再送」といった金銭に関わる依頼は、既知の電話番号で照合する - メールゲートウェイのログで、当該アドレスからの添付やリンクの取得実績を洗う 3番目を軽く見ないでください。実在の担当者名義で送れる状態を握った攻撃者にとって、次の一手はビジネスメール詐欺です。メールでの口座変更依頼は電話で確認する運用を、経理と購買に周知するところまでが今回の範囲になります。 ## パスキー全面移行に踏み切る条件と二段階認証の強化で足りる条件 「うちもパスキーにすべきか」への答えを、条件付きで言い切ります。 ### 先にパスキーへ移行すべき組織と部門の条件を規模でなく構造で決める 移行を先行させるべきなのは、次のいずれかに当てはまる場合です。第1に、社外の取引先と日常的にメールをやり取りし、担当者名義の信頼が業務の前提になっている部門。今回の講談社と同じ立ち位置で、なりすまし送信が成立したときの被害が自社の外へ広がります。第2に、メールアカウントがそのままシングルサインオンの起点になっており、1つ抜かれると業務システム全体へ横移動できる構成の組織。第3に、取引先や監査法人から認証方式について説明を求められる立場にある組織です。 当てはまるなら、部分導入ではなく対象部門の全員を移行させ、旧方式を閉じるところまでを1つの計画にしてください。半分だけ配る運用は、コストだけかかって攻撃者の経路が残ります。 ### 二段階認証の方式変更で当面足りる組織の条件と切り替え先の選び方 一方、外部とのメールのやり取りが限定的で、メールアカウントと基幹システムの認証が分離されており、利用者数が数十人規模にとどまる組織なら、全面移行を急ぐ必要はありません。SMSやプッシュ承認からハードウェアキーや端末バインドの方式へ切り替え、条件付きアクセスの規則を整えるだけで、費用対効果はパスキー全面移行を上回ります。 判断の分かれ目は利用者数ではなく、「1アカウント抜かれたときに、被害が自社の外へ出るか」の一点です。外へ出る構造なら移行を、社内で閉じるなら方式変更を選んでください。 ### 移行計画で見落とされやすい運用コストと現状把握の順序を決める判断基準 移行を決めた場合に見落とされるのは、導入費用ではなく移行後の運用です。認証器を紛失した利用者の回復手順、端末更新時の再登録、外部委託先のアカウント、共有アカウントの扱い。特に共有アカウントはパスキーの設計思想と相性が悪く、計画の途中で必ず詰まります。先に棚卸しして、共有をやめるか例外として隔離するかを決めておいてください。 順序としては、方式の選定より現状把握が先です。どのシステムがどの認証方式で守られ、フォールバック経路がどこに残っているか。認証まわりの実装状況を含めた洗い出しは[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で受託しており、そこで出た穴を潰してから移行計画を立てる順序を推奨します。 ## よくある質問 本事案について、実装担当者と管理部門から寄せられやすい質問に答えます。 ### 二段階認証を設定していれば今回の被害は防げましたか？ 方式によります。SMSや認証アプリのコード入力、プッシュ通知の承認といった方式は、偽のログイン画面が本物との中継役として動く攻撃に働きません。入力したコードはその場で本物へ転送され、成立したセッションが攻撃者に渡ります。防げる可能性が高いのは、資格情報がドメインと結び付いたFIDO2やパスキーです。 ### 流出したのがメールアドレスと氏名だけなら影響は小さいのではないですか？ 項目単体の機微性は高くありません。ただし本件の実害は、その連絡先へ実在の担当者を装ったフィッシングメールが553件送られた点にあります。連絡先情報の流出は、それ自体より次の攻撃の材料として評価すべきです。 ### パスワードを変更すれば侵害への対応は完了しますか？ 完了しません。中間者型の攻撃では、パスワードに加えて認証後のセッショントークンも持ち出されます。既存のトークンが有効なままなら攻撃者は入り続けられるため、講談社の対応にもセッション削除が併記されていました。手順書には、全セッションの失効、リフレッシュトークンの取り消し、アプリケーションパスワードの削除、多要素認証の再登録までを1セットで記載してください。 ### DMARCをrejectに設定すれば、なりすまし送信は止まりますか？ 本件の型には効きません。DMARCは送信ドメインを詐称するメールを対象とした仕組みで、正規のアカウントから正規のサーバーを経由したメールはSPFもDKIMも通過します。乗っ取り型への歯止めは、送信数と宛先ドメイン数にしきい値を設けて超過時に保留する統制のほうに置いてください。 ### 3日間検知できなかったのは監視製品を入れれば解決しますか？ 製品の導入だけでは足りません。今回の発覚の契機は大量送信という騒がしい挙動で、それ以前の静かな段階では検知に必要な材料が拾われていませんでした。転送規則の作成、連絡先の一括参照、見慣れないクライアントからの接続といった項目を監視対象へ入れて相関させ、条件から外れたセッションを自動で遮断する規則まで書いて初めて滞留が縮みます。 ## 関連記事 - [ショップサーブの情報漏えい最大885万件｜サーバー侵害とデータ外部送信の技術解説](https://www.issoh.co.jp/tech/details/16098/)：同時期に起きたホスト掌握型の事案。攻撃レイヤの比較用。 - [FIDO認証とは？仕組み・FIDO2/パスキー・導入判断までを解説](https://www.issoh.co.jp/tech/details/1440/)：本記事で移行先として挙げた方式の詳細。 - [WebAuthnとは？パスキー認証を実装する仕組みと登録・認証フロー・RP実装の要点](https://www.issoh.co.jp/tech/details/15375/)：自社システムへ後付けする際の実装手順。 - [多要素認証（MFA）とは？3つの認証要素と実装方式・耐フィッシングMFAを実装視点で解説](https://www.issoh.co.jp/tech/details/13314/)：方式ごとの詐取耐性の比較。 - [フィッシングとは？手口の種類・見分け方と企業が取るべき組織的対策を解説](https://www.issoh.co.jp/column/details/13262/)：手口の全体像と社内教育の材料。 - [SOCとは？SIEM・SOARとの違いと監視運用の仕組み・内製とアウトソースの判断を実装者向けに解説](https://www.issoh.co.jp/tech/details/13310/)：検知の当番体制をどう持つかの判断材料。 --- 出典: [講談社の個人情報流出3,812件｜フィッシング起点のアカウント侵害の技術解説]()（株式会社一創）