正規の取引先からのメールが迷惑メールと判定され、受信箱に届かない
判定基準が取引先のドメインや添付の形式に合っていないと、正規の発注・請求メールが迷惑メールと判定されます。申告で初めて表面化します。
GENZ, Inc.
情報システム部門の方へ
メールセキュリティ設定の
情報システム部門の方へ
メールセキュリティ設定の判定を第三者がテストします
ポリシー設定と検証を同じ担当者が担う体制では、意図どおりに判定される根拠が社内に残りません。設定者以外の第三者がテスト設計と実行を担います。
支援事例
支援実績5,000件以上
メールセキュリティソフトでよくある不具合
メールセキュリティソフトは、設定を変更していなくても判定の挙動が変わりうる性質を持ちます。導入直後に現れる不具合に加え、運用の中で積み上がるものまで、実際の送受信にどう現れるかを整理します。
正規の
社外宛の送信が保留されたまま解放されず、期日を越えて届く
保留条件が広すぎると、社外宛の送信が保留されたまま解放を待つ状態になります。承認が後回しになると、期日を越えてから相手先へ届きます。
誤検知のたびに追加した例外が重なり、拒否するはずの送信元を通過させる
誤検知の申告ごとに宛先・ドメインの例外を追加すると、例外の組み合わせにより、拒否するはずの送信元が通過します。設定の一覧では表面化しません。
暗号化した添付ファイルが取引先側で復号できず、再送が必要になる
暗号化方式と取引先の受信環境が対応していないと、復号できず再送が発生します。送信側の確認では検出できず、受信側の経路まで検証が必要です。
判定の基準が変わり同じ送信元の扱いが入れ替わる
機械学習を用いる製品では、定義ファイルの更新で判定基準が変わります。自社が設定を変更していない期間でも、同じ送信元のメールが保留されます。
残存した不具合により生じる問題
検証の形がないまま運用が続くと、遮断・漏えい・監査指摘という問題が業務と経営に影響する形で現れます。
静的テスト（レビュー）でおさえるべき観点
メールセキュリティ製品は、設定した側がそのまま動作の確認を行なう構図になりやすく、導入済みと意図どおりに判定されることの差が残りがちです。設定を変更せずに確かめられる観点を、レビューの形で整理します。
規程と設定の対応が示せないと、システム監査で是正の範囲が設定の棚卸し全体に広がり、部門の工数が割かれるおそれがあります。
社内規程の運用条項と、管理画面のポリシー設定値を照合する
規程で定めた運用条項と、管理画面のフィルターのポリシー設定値を項目ごとに照合します。規程改定のたびに対応表を更新し、設定が規程どおりであることを対応表の形で示せる状態にします。
確認する資料
- 社内規程
- ポリシー設定値
- 対応表
例外の積み上がりを照合しないまま運用が続くと、もとのポリシーの意図が失われた状態に誰も気づかず、遮断されるべきメールが通るおそれがあります。
許可リストと拒否リストの重複・矛盾を、例外の追加履歴と照合する
申告に応じて追加した例外が許可リストと拒否リストのどちらにあるかを一覧化し、同じ宛先やドメインが両方にないかを照合します。例外がポリシーの意図を打ち消していないかを定期的に確認します。
確認する資料
- 許可リスト
- 拒否リスト
- 例外追加履歴
保留条件が業務の期日と合わないと、発注や請求のメールが保留されたまま期日を越え、取引先との業務が止まるおそれがあります。
誤送信防止の保留条件と承認フローを、部門ごとの業務の期日と照合する
誤送信防止の保留条件と承認フローが、部門ごとの業務の期日と矛盾しないかを照合します。保留の上限時間と承認者の配置が業務の締め切りに間に合うかを、部門の利用者代表の申告内容と照合します。
確認する資料
- 保留条件
- 承認フロー
- 業務期日一覧
送信側だけの確認で方式変更を進めると、取引先が添付ファイルを受領できない状態が判明せず、返信の不着として業務影響が出るおそれがあります。
暗号化と添付の受け渡し方式を取引先の受領手順と照合する
暗号化の適用条件と添付の受け渡し方式が、取引先の受領手順で処理できるかを照合します。送信側の方式変更は受信側の経路に影響するため、取引先から届くメールの扱いまで検証範囲に含めます。
確認する資料
- 暗号化条件
- 受領手順
- 送受信記録
ログと検証記録が証跡要件を満たさないと、インシデント発生時に設定の不備か製品の判定機構かを切り分ける材料がなく、原因の説明ができないおそれがあります。
認証基盤の同期仕様とログ保存項目を証跡要件と照合する
認証基盤の同期仕様とログの保存項目が、システム監査で求められる証跡の要件を満たすかを照合します。設定の記録だけでは動作の根拠にならないため、検証の記録とログを監査で提出できる粒度に揃えます。
確認する資料
- 同期仕様書
- ログ保存項目
- 監査証跡要件
- 検証記録
動的テストの設計・実行のポイント
設定画面の表示だけでは判定結果を確かめられません。送受信を発生させて検証する動的テストの設計と実行の要点を整理します。
STEP 01
判定条件のユニットテストポリシーと保留・暗号化の条件を対象
どう確かめるか
判定条件ごとに境界値でテストし、遮断と通過を確かめる
フィルターのポリシー、保留条件、暗号化の適用条件について、境界値となるメールを意図的に発生させて検証します。遮断すべきメールが遮断され、通過すべきメールが届くことを確かめます。
- 01判定条件の境界値となるテストケースを設計します
- 02遮断と通過の条件を意図的に発生させて検証します
- 03誤検知と見逃しの有無を条件ごとに記録します
OUTPUT判定条件のテスト項目書
STEP 02
連携部分の統合テスト管理画面と連携先の接続を対象
どう確かめるか
社内システムとの連携を送受信の実行で確認する
メール基盤と社内システムの間で、添付ファイルの受け渡しとログの転送が意図どおりに処理されるかを送受信の実行で確かめます。設定画面の表示と判定結果の対応は実行による検証が必要です。
- 01受信経路と送信経路の接続構成を整理します
- 02連携先との間で送受信を実行して確認します
- 03設定値と判定結果の対応を記録します
OUTPUT連携確認の結果記録
STEP 03
業務シナリオのシステムテスト利用者の日常の送受信手順を対象
どう確かめるか
業務シナリオで送受信から保留・承認・解放・不達通知までを通して確認する
取引先への送信、添付ファイルの受け取り、保留から承認・解放、不達通知まで、利用者の業務手順に沿って順に確かめます。誤送信防止の保留が業務を止めないこともあわせて確認します。
- 01取引先との送受信の業務シナリオを定義します
- 02保留・承認・解放・不達通知を通して検証します
- 03業務上の影響がないかを利用手順で確認します
OUTPUT業務シナリオの検証記録
STEP 04
パフォーマンステストと回帰テスト負荷条件と更新後の判定を対象
どう確かめるか
負荷条件でのパフォーマンステストと例外追加後の回帰テスト
大量送信や大容量添付の条件で遅延と保留の挙動を確かめるパフォーマンステストと、例外追加や製品側の定義ファイル更新の後に既存の判定が変わっていないかを確かめる回帰テストを実施します。
- 01大量送信・大容量添付の負荷条件を設定します
- 02遅延と保留の挙動をパフォーマンステストで確認します
- 03例外追加と更新の後に回帰テストを実施します
OUTPUT負荷・回帰テストの結果
GENZが代行するメールセキュリティソフトのテスト
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 自社の業務メールのパターンから検証範囲を切り出せます
- 確かめた条件と残るリスクが読める報告書を受け取れます
- 設定を行った主体と異なる第三者の視点で検証できます
- 仕様変更がない期間の回帰テストの型を確保できます
設定した範囲を、設定していない視点から検証します
メールセキュリティの設定は、設定した担当者が動作を確かめる構図になりがちです。GENZは設定に関与しない第三者の視点で、ポリシー・保留条件・暗号化条件の判定をテスト設計から検証し、結果を記録に残します。
経路と連携先の範囲からテスト設計を起こす
機能一覧ではなく、受信経路・送信経路・端末・管理画面・連携先という範囲の軸で、確かめる条件の組み合わせを切り出します。
設定担当とは別の立場で検証範囲と結果を記録
設定を行った担当者とは別の立場でテストを設計・実行し、「どこまで確かめたか」が社内に残る形で検証範囲と結果を記録します。
体制と期間に応じて委託範囲を区切る
発注側主導・ベンダー主導の別や品質保証の配置に応じて、委託する範囲と関与の形を区切り、既存の体制へ合わせて進めます。
条件と結果、残るリスクを報告
確かめた条件・結果・残るリスクを報告書とテスト項目書にまとめ、リリース判断と監査への提出に使える形で納品します。
ご相談から納品までの流れ
メールセキュリティのテスト外注は、現状の確認から報告書の納品と再確認までの工程で進みます。
ヒアリング（現状と要望の確認）
現在の設定値と誤検知の申告状況、更改の期限と説明が必要な範囲を伺います。
テスト設計と見積もり
受信・送信・端末・管理画面の範囲を切り分け、期間と費用を示します。
テスト実施と結果の共有
設定値と判定結果の対応を送受信の実行で検証し、中間の結果を共有します。
報告書の納品と再確認
検証範囲・結果・残るリスクを報告書にまとめて納品し、内容を再確認します。
設定と検証を分ける第三者の視点で
メールセキュリティの検証範囲と優先順位を、GENZにご相談ください
製品の機能比較では、設定が意図どおりに判定される根拠は示せません。GENZが受信・送信・端末・管理画面の範囲でテストを設計し、リリース判断と監査に使える報告書をお渡しします。