【実務・中級編】【上級者向け】受信メールのヘッダー情報を解析し、なりすましメールの疑いがある場合に隔離フォルダへ移動するセキュリティ自動化 – Outlook VBA解析バイブル

Architecting a Security Sentinel: 高度なヘッダー解析による「なりすまし検知」自動化の極意

業務自動化の現場において、多くのエンジニアは「受信したメールを特定のフォルダに分ける」程度の、表面的な実装で満足してしまう。しかし、真にプロフェッショナルなアーキテクトが目指すべきは、単なる「整理」ではない。システムに侵入しようとする脅威を、メールのメタデータレベルで検知・隔離する「セキュリティ・センチネル（監視兵）」の構築である。

本記事では、Outlook VBAを用い、メールヘッダー内の `Authentication-Results`（SPF, DKIM, DMARCの結果）を解析し、なりすましの疑いがあるメールを即座に隔離フォルダへ隔離する、堅牢な設計手法を伝授する。

「動けばいい」というコードを書くのは今日で終わりにしよう。ここでは、オブジェクトのライフサイクル、イベントの競合、そして例外処理の設計という、プロダクション環境で求められる極限の知見を共有する。

1. なぜ、あなたの「振り分けロジック」は脆弱なのか

一般的な開発者が書く `Items.Add` イベントを利用した振り分けロジックには、致命的な弱点が3つある。

1. イベントの取りこぼし（Race Condition）:
大量のメールが同時に流入した際、`Items.Add` は全てのオブジェクトを確実にハンドリングできる保証がない。
2. 無限ループの罠:
「メールを移動する」という操作自体が、再び「アイテム追加イベント」をトリガーし、再帰的に処理が走り続けるリスクがある。
3. 解析精度の欠如:
`SenderEmailAddress` だけを見て判断するのは素人の仕事だ。攻撃者は送信元アドレスを容易に偽装できる。我々が注視すべきは、メールサーバーが書き込んだ「認証結果ヘッダー」である。

これらを克服するためには、`NewMailEx` イベントの採用と、ロジックとUIの完全な分離（Separation of Concerns）が不可欠となる。

2. アーキテクチャ設計：検知エンジンとイベントハンドラの分離

堅牢なコードを書くための鉄則は、「Outlookのイベントを監視する部分」と「メールの正当性を判定するロジック」を分けることである。

• Event Handler (Module): Outlookからの信号を受け取り、解析エンジンにタスクを投げる。
• Security Engine (Class Module): ヘッダーを解析し、`True/False` の判定結果のみを返す。

この設計により、テストコードが書きやすくなり、将来的に解析ロジックを複雑化（例えば外部APIとの連携など）させても、メインのイベント駆動ロジックを破壊せずに済む。

3. 実装：プロフェッショナル・コード例

以下に、そのままプロダクション環境の設計思想として利用できるコードを示す。

Step 1: 検知エンジン（Class Module: `clsSecurityEngine`）

まずは、ヘッダーを解析する「脳」を作る。ここでは `Authentication-Results` ヘッダーから `spf=fail` や `dkim=fail` を探査する。

' Class Module: clsSecurityEngine
Option Explicit

Private Enum DetectionResult
    Safe = 0
    Suspicious = 1
    Critical = 2
End Enum

''' <summary>
''' メールのヘッダーを解析し、なりすましのリスクを判定する
''' </summary>
''' <param name="mailItem">解析対象のMailItemオブジェクト</param>
''' <returns>判定結果 (True: 隔離が必要, False: 安全)</returns>
Public Function IsSpoofingDetected(ByVal mailItem As Outlook.MailItem) As Boolean
    On Error GoTo ErrorHandler
    
    Dim headerText As String
    Dim isSuspicious As Boolean
    
    ' 1. ヘッダー情報の取得
    ' InternetMessageHeadersプロパティを使用することで、詳細なメタデータにアクセスする
    headerText = mailItem.PropertyAccessor.GetProperty("http://schemas.microsoft.com/mapi/proptag/0x007D001E")
    
    ' 2. 判定ロジック (Authentication-Results の解析)
    ' SPF, DKIM, DMARC のいずれかが 'fail' または 'softfail' であるかをチェック
    ' ※ 実際の運用では、組織のポリシーに合わせて判定基準を調整すること
    isSuspicious = False
    
    ' 簡易的な文字列解析（プロフェッショナルな現場では、正規表現(VBScript.RegExp)の使用を推奨）
    If InStr(1, headerText, "spf=fail", vbTextCompare) > 0 Then isSuspicious = True
    If InStr(1, headerText, "dkim=fail", vbTextCompare) > 0 Then isSuspicious = True
    If InStr(1, headerText, "dmarc=fail", vbTextCompare) > 0 Then isSuspicious = True
    
    ' 3. 追加の脅威検知 (例: 送信元ドメインとヘッダーの不一致など)
    ' ここに高度なロジックを実装可能
    
    IsSpoofingDetected = isSuspicious
    Exit Function

ErrorHandler:
    ' 解析失敗は「安全」とせず、念のため「疑わしい」として扱うのがセキュリティの定石
    Debug.Print "Error in IsSpoofingDetected: " & Err.Description
    IsSpoofingDetected = True 
End Function

Step 2: メインハンドラ（Standard Module: `modMain`）

次に、イベントをトリガーする部分を書く。ここでは `NewMailEx` を使い、メールIDを介してオブジェクトを取得する。

' Standard Module: modMain
Option Explicit

Private WithEvents olApp As Outlook.Application
Private engine As clsSecurityEngine
Private Const ISOLATION_FOLDER_NAME As String = "【隔離】なりすまし疑い"

''' <summary>
''' Outlook起動時に実行される初期化ルーチン
''' </summary>
Public Sub InitializeSecuritySentinel()
    Set olApp = Outlook.Application
    Set engine = New clsSecurityEngine
    Debug.Print "Security Sentinel Initialized."
End Sub

''' <summary>
''' NewMailExイベント: 新着メールのIDを受け取り、安全に処理する
''' </summary>
Private Sub olApp_NewMailEx(ByVal EntryID As String)
    Dim ns As Outlook.NameSpace
    Dim mailItem As Outlook.MailItem
    Dim targetFolder As Outlook.Folder
    
    On Error GoTo ErrorHandler
    
    Set ns = Application.GetNamespace("MAPI")
    ' EntryIDから直接オブジェクトを特定する（Items.Addより遥かに堅牢）
    Set mailItem = ns.GetItemFromID(EntryID)
    
    ' MailItem以外（会議出席依頼など）はスキップ
    If mailItem.Class <> olMail Then Exit Sub

    ' 1. セキュリティエンジンの呼び出し
    If engine.IsSpoofingDetected(mailItem) Then
        Debug.Print "Threat Detected: " & mailItem.Subject
        
        ' 2. 隔離フォルダの取得（存在しない場合は作成）
        Set targetFolder = GetOrCreateFolder(ns, ISOLATION_FOLDER_NAME)
        
        ' 3. 移動処理
        ' 注意: 移動によりオブジェクトの参照が変わるため、移動後にプロパティに触れてはいけない
        mailItem.Move targetFolder
        Debug.Print "Mail moved to isolation folder."
    End If

    Exit Sub

ErrorHandler:
    ' 実行時エラーが発生しても、Outlook全体のプロセスを止めないよう、ログ出力に留める
    Debug.Print "Critical Error in NewMailEx: " & Err.Description
End Sub

''' <summary>
''' フォルダの存在確認および作成を行うヘルパー関数
''' </summary>
Private Function GetOrCreateFolder(ByVal ns As Outlook.NameSpace, ByVal folderName As String) As Outlook.Folder
    Dim inbox As Outlook.Folder
    Dim target As Outlook.Folder
    
    Set inbox = ns.GetDefaultFolder(olFolderInbox)
    
    On Error Resume Next
    Set target = inbox.Folders(folderName)
    On Error GoTo 0
    
    If target Is Nothing Then
        Set target = inbox.Folders.Add(folderName)
    End If
    
    Set GetOrCreateFolder = target
End Function

4. 実務における「落とし穴」と回避策

オブジェクトのライフサイクル管理

VBAはCOMオブジェクトの管理が非常にデリケートだ。特に `mailItem.Move` を実行した瞬間、その `mailItem` オブジェクトは元のフォルダから消滅し、メモリ上の参照が不安定になる。
「移動した後のオブジェクトに対して、再度プロパティ（SubjectやSenderなど）にアクセスしない」。これは鉄則だ。

パフォーマンスへの配慮

`NewMailEx` はメールが届くたびに呼び出される。ここで重い処理（外部のデータベースへのSQLクエリや、複雑すぎる正規表現）を行うと、OutlookのUIスレッドをブロックし、ユーザーの操作を著しく阻害する。
解析ロジックは常に $O(1)$ または $O(n)$（nはヘッダー行数） の計算量で完結させるよう設計せよ。

ログと監査

セキュリティツールにおいて、「なぜそのメールが隔離されたのか」の証跡がないことは致命的だ。
実務では、`Debug.Print` ではなく、テキストファイルやローカルのSQLiteデータベースへ、`EntryID`, `Timestamp`, `Reason` を書き出す仕組みを必ず組み込むべきである。

結論：エンジニアとしての誇り

自動化ツールを作る際、「とりあえず動く」コードを書くのは簡単だ。しかし、セキュリティという、一歩間違えれば業務を停止させかねない領域において、その「甘さ」は許されない。

オブジェクトの挙動を理解し、エラーを予測し、保守性の高い構造を設計する。このプロセスを経て初めて、あなたの書いたコードは「ツール」から「システム」へと昇華する。

次回の実装からは、このアーキテクチャを意識してほしい。健闘を祈る。