内部メールに見えるフィッシングが、なぜ防げないのか

山崎行政書士事務所
3 日前
読了時間: 3分

――メール設定ミスが生む“信頼の詐称”という法務リスク

はじめに

近年、フィッシング被害の相談で増えているのが、「外部からの攻撃なのに、内部メールに見えた」というケースです。

標的型攻撃でもなく、特定企業を狙った高度攻撃でもありません。原因はもっと身近で、自社のメール構成そのものにあります。

攻撃の正体は「認証突破」ではない

このタイプの攻撃で誤解されがちなのは、「Microsoft 365 や Defender が突破されたのではないか？」という点です。

実際には、認証が破られているわけではありません。

攻撃者が突いているのは次のポイントです。

メールルーティングが複雑化している
外部サービス（中継・セキュリティ・業務システム）とのコネクタ設定
SPF / DKIM / DMARC の“部分的な緩和設定”

これらが組み合わさることで、外部から送られたメールが「内部送信」として処理される状態が生まれます。

「内部扱い」になると何が起きるか

メールが内部送信と認識されると、次の現象が起きます。

件名に【外部】が付かない
ユーザーの迷惑メール耐性が一気に下がる
一部のセキュリティ検査がスキップされる
結果としてクリック率が跳ね上がる

つまりこれは、**技術的なすり抜けではなく「信頼の悪用」**です。

なぜ企業はこの状態に気づけないのか

理由は単純です。

メールは届いている
業務上の不具合は起きていない
監査でも「設定済み」と見なされる

“動いている構成”ほど、見直されません。

特に次のような構成は要注意です。

メール中継サービスを複数経由している
海外拠点・子会社との共用ドメイン
例外設定だらけの SPF
DMARC が none / quarantine のまま

クラウド法務の視点：これは「設定事故」ではない

ここで重要なのは、この問題が 単なるIT運用ミスでは終わらない という点です。

被害が発生した場合、問われるのは次の論点です。

なぜ内部詐称を防げる構成にしていなかったのか
設計変更・例外設定の承認責任は誰にあったのか
インシデント時の説明責任を誰が負うのか

これは、「技術設計」と「統制・責任設計」が分離している組織構造そのものが問われます。

MFAを入れていても安心できない理由

多要素認証（MFA）を導入している企業でも、次のような被害が発生しています。

フィッシングページで資格情報＋MFA入力
セッション情報の横取り
正規ログインとして処理

つまり、メール段階で防げなかった時点で負けが確定する構成になっているのです。

本当に必要なのは「構成の棚卸し」

対策として重要なのは、ツール追加ではありません。

メール経路の可視化
認証が「どこで」「誰の判断で」緩和されているか
例外設定の存在理由と期限
インシデント時の説明文を事前に書けるか

これらを整理しない限り、Defender を強化しても、MFA を厳格化しても、同じ事故は形を変えて再発します。

山崎行政書士事務所のクラウド法務が扱う範囲

当事務所では、この種の問題を「セキュリティ製品の話」ではなく、次の観点で整理します。

構成と責任の対応関係
契約・規程・実運用のズレ
説明可能性（なぜこの設定だったのか）
インシデント後に残る文書リスク

クラウドは設定した瞬間から法的構造物です。動いているから安全、ではありません。

まとめ

内部メールに見えるフィッシングは、攻撃者の巧妙さよりも、企業側の構成思想の隙を突いています。

「技術は担当者任せ」「法務は事後対応」この分断こそが、最大のリスクです。