0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Microsoft 365移行で生まれたセキュリティの盲点 ― SEGからAPIベースへの転換

Last updated at Posted at 2025-12-12

Check Point マーケティング 大植です。

記事の目的

Microsoft 365やGoogle Workspaceへの移行が一巡し、メール基盤をクラウドで運用することが当たり前になりました。TeamsやSlackでのコミュニケーション、SharePointやOneDriveでのファイル共有も日常の風景です。

この環境変化の中で、Eメールセキュリティの世界に大きな転換点が訪れています。

2023年Q2、Forresterのアナリストは「約10年の停滞期を経て、Eメールセキュリティ市場が息を吹き返した」と評し、 「黄金期(Golden Age)」 と呼びました。当時そのアナリストレポートに感銘を受けたのを今でも覚えています。また、2024年12月には、Gartnerが約5年ぶりにMagic Quadrantを刷新し、2025年12月も更新しています。

成熟したはずの市場が、なぜ今動き出したのか、本記事では、技術的な変遷を振り返りながら、その背景を解説します。

過去10年で何が変わったのか

メール基盤のクラウド移行

かつて企業のメールシステムは、自社のデータセンターで運用されていました。Windows環境ではExchange Server、Linux環境ではPostfixやSendmailでメールサーバーを構築し、運用管理していた時代です。今日、Gartnerの推計では70%以上の組織がMicrosoft 365やGoogle Workspaceを利用しています。メールサーバーを自社で構築・運用する企業は少数派になりました。

コミュニケーション手段の多様化

もうひとつの大きな変化は、メール以外のコミュニケーション手段の台頭です。TeamsやSlackでのチャットが日常化し、ファイルはメール添付ではなくSharePointやGoogle Drive、BoxやDropboxのリンクで共有する。こうした働き方が標準になりました。

ここで見落とされがちな問題があります。

従来のEメールセキュリティは、添付ファイルをサンドボックスで検査し、未知のマルウェアを検知していました。しかし、ファイル共有がクラウドストレージのリンクに置き換わったことで、この検査対象から抜け落ちているケースが生まれています。高機能なサンドボックスを導入していても、検査されないファイルには意味がありません。レガシーなEメールセキュリティ構成では、この盲点に気づいていないことがあります。

それでもEメールは最大の攻撃経路

環境は変わりました。しかし、Eメールが最大の攻撃経路/攻撃ベクターであるという事実は変わっていません。Check Pointの2025年セキュリティレポートによると、初期の攻撃経路ととして68%が電子メール経由で行われています。ソーシャルエンジニアリングを組み合わせたフィッシングは依然として最大の脅威であり、攻撃手法は年々巧妙化しています。

コロナ禍を経て、ビジネスメール詐欺(BEC)も急増しました。2019年から2021年にかけては、リモートワークの普及を背景に被害額が65%増加。FBIの報告によると、2013年から2023年までの累計被害額は約555億ドルに達し、2024年単年でも約27.7億ドルの被害が報告されています。

アカウント乗っ取り(ATO)の台頭

クラウドメール環境で急増しているのが、アカウント乗っ取り(ATO)です。Microsoft 365などのアカウントを乗っ取り、正規ユーザーとして内部から攻撃を行います。

  • 2019年から2021年にかけて、ATO攻撃は307%増加
  • 2023年のATO関連損失は約130億ドル(2022年は110億ドル)
  • 2024年には米国成人の 29% がATOを経験(2021年は22%)

ATOへの基本的な対策は、MFA(多要素認証)の導入です。ただ、MFAにおいても、AiTM攻撃やMFA疲労攻撃といった迂回・突破する攻撃手法も増加しており、フィッシング耐性を持つパスキーへの移行が進むと見ています。

認証強化はもちろん重要ですが、APIベースのMicrosoft 365セキュリティを活用することで、ログイン元や行動パターンの監視、ATOの早期検知・防止が可能になります。次章では、このEメールセキュリティの技術変遷について解説します。

Eメールセキュリティの変遷

では、セキュリティ技術はどのように進化してきたのでしょうか。

SEG(Secure Email Gateway)の時代

2000年代、Eメールセキュリティの主流は SEG(Secure Email Gateway) でした。当初は、メールサーバーの前段にアプライアンスを設置するオンプレミス構成が一般的でした。

転機となったのは、MessageLabs(2008年にSymantecが買収)の台頭です。これを契機にSEGのクラウドサービス化が加速しました。DNSのMXレコードを変更し、すべてのメールをセキュリティベンダーのクラウド基盤を経由させてから自社のメールサーバーに配送する構成が主流となります。当時、大変画期的なクラウドサービスだったと覚えています。オンプレミスのアプライアンスを持たずとも、高度なメールセキュリティを利用できるようになりました。

SEGを中心に、防御機能面でも進化し、スパムフィルタリングやアンチウイルスに加え、未知の脅威に対応するサンドボックスがメール検査に採用されるようになり、SEGは成熟期を迎えました。

市場の停滞

SEGは広く普及し、2015年にはGartnerがMagic Quadrantを終了させるほど成熟した市場と見なされました。理由は「導入率がほぼ100%に達した」から。技術的なイノベーションは停滞し、市場は約10年間、大きな変化がありませんでした。

APIベースへのシフト

この停滞を打ち破ったのが、APIベースのアプローチです。

Microsoft 365やGoogle WorkspaceはAPIを公開しています。このAPIを利用すれば、MXレコードを変更せずに、メールボックスへ直接アクセスしてセキュリティスキャンを実行できます。

2021年、GartnerはこのアプローチをICES(Integrated Cloud Email Security)として新たなカテゴリに定義しました。

このカテゴリには数多くのスタートアップが参入し、市場は活性化しました。一方で、脅威防止のテクノロジーはスタートアップだけでは難しい領域も多いことが現実です。近年では、Check PointによるAvanan買収(2021年)、ProofpointによるTessian買収(2023年)、そしてFortinetによるPerception Point買収(2024年)など、大手ベンダーがAPIベースの新興ベンダーを買収し、自社の未知のマルウェア対策や、データ漏洩保護(DLP)といった脅威防止エンジンと共に提供することで、エンタープライズでのAPIベースセキュリティの採用が進展しています。

APIベースのアプローチには、SEGにはない特徴があります。

導入の容易さ ― MXレコード変更が不要。APIを接続するだけで、数分で稼働を開始できます。メールフローを変更しないため、既存環境への影響も最小限です。

内部メールの可視化 ― SEGは外部との送受信が主な対象で、組織内のメールは対象外になりがちでした。APIベースなら内部メールも監視対象にできます。ATOで乗っ取られたアカウントからの内部攻撃にも対応可能です。

BEC・ATOへの対応力 ― SEGはメールの経路上で検査を行うため、メールコンテンツのスキャンが中心になります。一方、APIベースはMicrosoft 365やGoogle Workspaceに直接接続し、ログイン元のIPアドレスや地理情報、アクセス時間帯、過去の行動パターンといったコンテキスト情報を取得できます。「普段は東京からログインしているユーザーが、突然海外からアクセスしている」「深夜に大量のメール転送ルールが設定された」といった異常を検知し、ATOの兆候を捉えることが可能です。BECについても、送信者の行動履歴や文体の変化を分析することで、なりすましを検知できます。

コラボレーションツールへの拡張 ― Microsoft Graph APIなどを活用すれば、メールだけでなくTeams、SharePoint、OneDriveなども同じアーキテクチャで保護できます。冒頭で述べた「クラウドストレージの盲点」にも対応可能です。

ネイティブセキュリティとアドバンスドセキュリティ

クラウドメールのセキュリティを考える上で、2つの層を理解しておく必要があります。

ネイティブセキュリティとは、Microsoft 365やGoogle Workspaceに標準搭載されているセキュリティ機能です。Microsoft 365であればExchange Online Protection(EOP)、Google WorkspaceであればGmailのスパムフィルタがこれにあたります。既知のスパムやマルウェアのフィルタリングが主な役割です。

アドバンスドセキュリティとは、ネイティブセキュリティでは対応しきれない脅威に対処するための追加ソリューションです。サンドボックスによる未知のマルウェア検知、BECの行動分析、ATOの異常検知などが含まれます。Microsoft Defender for Office 365もアドバンスドセキュリティに分類されますが、多くの組織ではサードパーティのセキュリティベンダー製品を採用しています。

EOPだけでは、ゼロデイ攻撃や標的型フィッシング、BEC、ATOといった高度な脅威には対応できません。これらに対処するには、アドバンスドセキュリティの導入が必要です。

SEGの配置順序の課題

ここで、アドバンスドセキュリティの配置順序について考えてみます。

SEGはMXレコードを変更し、ネイティブセキュリティの前段に配置されます。すべてのメールがSEGを経由してからEOPに届く構成です。この場合、SEGが大半の脅威を処理するため、ネイティブセキュリティがどの程度機能しているのか見えにくくなります。

一方、APIベースのソリューションはネイティブセキュリティの後段で動作します。まずEOPが処理を行い、それをすり抜けてきた脅威をAPIベースで検知する構成です。

後段配置には明確なメリットがあります。

  • ネイティブセキュリティの実力が可視化される ― 何がすり抜けてきたかを把握できる
  • アドバンスドセキュリティの価値が明確になる ― ネイティブで防げなかった脅威を検知した実績が見える
  • 投資対効果の判断がしやすい ― 各レイヤーの貢献度を定量的に評価できる

APIベースでもインライン保護は可能

「APIベースは後段で動作する」と述べましたが、これは「受信後にしか対応できない」という意味ではありません。Check Point Harmony Email & Collaborationでは、メールフロールールとの連携により、ネイティブセキュリティ通過後かつ受信ボックス到達前のタイミングで検査・ブロックを行うインライン保護が可能です。APIの柔軟性を活かしつつ、SEGと同様の「届く前に止める」防御を実現できます。
M365-HEC_image.png

Forresterの調査では、63%のセキュリティリーダーが2社以上のEメールセキュリティを併用しています。ネイティブセキュリティを基盤に、アドバンスドセキュリティを適切に配置する多層構成が、現在のベストプラクティスとなっています。

おわりに

メール基盤がクラウドに移行し、コミュニケーションがTeamsやSharePointに広がり、攻撃はBECやATOへと進化しました。約10年の停滞を経てEメールセキュリティ市場が再び動き出した背景には、こうした環境と脅威の変化があります。

ここ数年は SASE、なかでも SSEの分野のセキュリティが話題となっていましたが、SSEのZTNAやWebセキュリティに注目があたる反面、Eメールセキュリティにおいても大きな転換期を迎えています。

SEGからAPIベースへ、メール単体からコラボレーション全体へ。技術の軸足が移りつつある今、自社のセキュリティ構成が現在の脅威に対応できているか、改めて見直してみてはいかがしょうか。

宣伝


参考情報

  • Gartner, Magic Quadrant for Email Security Platforms, December 2024
  • Forrester, The Forrester Wave: Enterprise Email Security, Q2 2023
  • FBI IC3, 2024 Internet Crime Report
  • FBI IC3, Public Service Announcement: Business Email Compromise, September 2024
  • Check Point, 2025 Security Report
  • Sift, Q3 2023 Digital Trust & Safety Index
  • Security.org, Account Takeover Annual Report 2024
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?