GDPRメールセキュリティの7つのギャップが€400M以上の罰金を引き起こす

メールは、GDPR罰則につながるデータ保護障害において最も悪用される脆弱性であり続けています。2020年以降、メール関連の侵害に対して科された€400M以上の罰金には共通のパターンがあります。組織は基本的な認証制御の実装、不正な送信者の監視、または大規模なデータ流出が発生する前の侵害の検出に失敗していました。

Coupangの2024年の罰則はこのパターンを例示しています。韓国の小売業者は暗号化が失敗したからではなく、不適切なアクセス制御と監視により、侵害されたメールチャネルを通じて不正な第三者が顧客データにアクセスできたため、€15Mの罰金に直面しました。侵害は高度なものではなく、DMARC、送信者検証、不正アクセス検出で発見できたはずの認証ギャップを悪用したものでした。

GDPRはDMARCを名指しで義務付けてはいません。第32条と第5条(1)(f)は「適切な技術的および組織的措置」と「リスクに適した」処理セキュリティを要求しています。メール認証制御はこれらの目標をサポートします。執行当局がフィッシング、スプーフィング、または不正な送信者アクセスがデータ漏洩に寄与した侵害を調査する際、組織がそれを防ぐための合理的な措置を実装したかどうかを評価します。

この簡潔な資料は、GDPR罰則決定に現れる7つのメールセキュリティギャップを特定し、それぞれを防止可能な認証障害と結びつけ、組織がそれらをどのように解消できるかを説明します。

I. ギャップ1: ドメインレベル認証の欠如 → 未検出のスプーフィング

2020年以降、メール関連の情報漏えいに対して4億ユーロを超えるGDPR制裁金が科されており、その中にはCoupangに対する1,500万ユーロの制裁金も含まれています。

コンプライアンス違反:
組織はSPFレコードもDMARCポリシーも公開せず、またはDMARCをp=noneのまま無期限に放置します。脅威アクターは内部ドメインをスプーフィングして従業員、パートナー、または顧客を標的にします。スプーフィングされたメールが資格情報の盗難やデータ流出につながったとき、規制当局は「ドメインなりすましを防ぐための措置を実装しましたか?」と尋ねます。

何が間違い得るか:
SPFはDNS検索がタイムアウトした場合(temperror)、またはレコードが10回のDNS検索を超えた場合(permerror)に静かに失敗する可能性があります。DMARCは認証を通過してもエンベロープ送信者がヘッダーFromアドレスと異なる場合、アラインメントに失敗する可能性があります。認証通過は受信ボックス配置を保証せず、認証失敗も必ずしも即座の拒否を意味しませんが、エンフォースメントの欠如は重要な検出制御を除去します。

予防策:
DMARC監視を開始し、p=quarantineまたはp=rejectエンフォースメントに移行し、タイムラインを文書化します。DMARCエンフォースメントは受信ボックス配置を保証しませんが、受信サーバーによって尊重された場合、p=rejectはSMTP配信中に未認証のメッセージを拒否するよう指示します。

GDPRの対象となる組織は、メールセキュリティプログラムの一環としてDMARCエンフォースメントを実装することが一般的です。Skysnag Protectを使用して正当な送信者を特定し、不正なソースを検出し、サブドメイン、事業単位、送信者グループごとにエンフォースメントをステージングします。

GDPR第32条との関連:
第32条は「技術的および組織的措置の有効性を定期的にテスト、評価、検証するプロセス」を要求しています。エンフォースメントのないドメインには、リアルタイムでスプーフィングをブロックまたは検出するメカニズムがありません。

II. ギャップ2: 監視されていないサードパーティ送信者 → シャドーITメール

承認済みの企業送信者、シャドーITサービス、および未承認ソースからの脅威ベクトルを示した3層構造のメールアーキテクチャ。

コンプライアンス違反:
マーケティングプラットフォーム、CRMツール、サポートチケットシステム、SaaSアプリケーションが組織に代わってメールを送信します。ITは在庫を管理していません。従業員はITレビューなしでツールを承認します。不正または侵害されたサービスがスプーフィングメッセージを送信し、組織は侵害後にのみ問題を発見します。

何が間違い得るか:
DKIM署名を公開しない、またはSPFアラインメントに失敗するサードパーティ送信者は、サービスが正当であってもDMARCに失敗します。組織がp=rejectでDMARCを実施する場合、審査されていないサービスからの正当なメールが拒否される可能性があります。組織が実施しない場合、攻撃者は組織が承認したことのないサービスを使用してスプーフィングできます。

予防策:
送信者在庫を維持します。企業ドメインに代わって送信するサービスを承認する前にIT承認を要求します。DMARC集約レポートを使用して不正な送信者を発見します。Skysnag Protectは、あなたに代わって送信するすべてのソースを表示し、承認された在庫にないソースにフラグを立てます。

GDPR第28条との関連:
第28条は、組織が「十分な保証を提供する」プロセッサーを使用し、「適切な技術的措置」を実装することを要求しています。ITがどのプロセッサーがメールを送信しているかを特定できない場合、それらの保証を評価できません。

III. ギャップ3: レポート収集なしの静的DMARCレコード → コンプライアンス劇場

コンプライアンス違反:
組織はrua=mailto:[email protected]を含むDMARCレコードを公開しますが、誰もメールボックスを監視しません。レポートは未読のまま積み重なります。組織は新しい脅威、不正な送信者、または認証失敗を特定できません。侵害が発生したとき、組織は監視がアクティブであったことを実証できません。

何が間違い得るか:
DMARC集約レポートは毎日数百のソースからXML形式で届きます。自動解析なしでは、レポートデータは使用不可能です。DNS配信失敗、メールボックスクォータ問題、誤ルーティングにより、レポートが静かに到着しなくなる可能性があります。監視のない静的レコードはセキュリティ上の利点を提供しません。

予防策:
管理されたDMARC監視を使用します。Skysnagデプロイメントでは、レポート先はSkysnagによって生成および維持されます。レポートは解析、正規化され、送信者のコンプライアンス、認証結果、新しいソースをリアルタイムで表示するダッシュボードに表示されます。

次のような従来の静的レコード:

v=DMARC1; p=none; rua=mailto:[email protected]

は機能しますが、レポートが積極的に受信、解析、分析、および対処される場合のみです。より良いアプローチは、Skysnagを通じてDMARC監視を開始し、ドメイン用に管理されたレコードを生成することです。

GDPR第32条との関連:
第32条は「継続的な機密性、完全性、可用性、および回復力を確保する措置」を要求しています。監視のないレコードは継続的な可視性を提供しません。

IV. ギャップ4: エンフォースメントポリシーなし → 不正な送信者が通過

コンプライアンス違反:
組織はp=noneでDMARCを公開し、そのままにしておきます。DMARCレポートは失敗したソースを示しますが、エンフォースメントアクションは取られません。脅威アクターはエンフォースメントの欠如を発見し、ドメインを大規模にスプーフィングします。フィッシングがデータ侵害につながったとき、執行当局は組織が合理的なブロッキング措置を実装したかどうかを評価します。

何が間違い得るか:
受信サーバーによって尊重された場合、p=rejectはSMTP配信中に未認証のメッセージを拒否するよう指示し、メッセージは受信ボックスまたはスパムフォルダに到達すべきではありません。ただし、エンフォースメントはポリシーを尊重する受信サーバーに依存します。一部のフォワーダー、メーリングリスト、および誤設定された受信者は尊重しません。DMARCエンフォースメントはどこでも拒否を保証しませんが、スプーフィング成功率を大幅に削減します。

組織は正当なメールをブロックすることを恐れているため、p=noneのままであることが一般的です。その恐れは妥当です。パーセンテージベースのロールアウト(pct=)を主要戦略として依存することは避けてください。現在のDMARC対応プログラムは、ドメイン、サブドメイン、送信者グループ、およびビジネス機能ごとにエンフォースメントをステージングする必要があります。

予防策:
DMARC集約レポートを使用してすべての正当な送信者を特定します。それぞれについてSPFとDKIMを検証します。まずリスクの低いサブドメインでエンフォースメントをテストします。送信者のコンプライアンスが向上するにつれて、本番ドメインをp=quarantine、次にp=rejectに移行します。Skysnag Protectを使用して送信者認証ステータスを追跡し、エンフォースメントを安全にステージングします。

GDPR第5条(1)(f)との関連:
第5条(1)(f)は「不正または違法な処理」から保護するための「適切なセキュリティ」を要求しています。不正使用をブロックするよう受信者に指示しないドメインは、より弱い保護を提供します。

V. ギャップ5: DKIMローテーションなし → 鍵の侵害が未検出

コンプライアンス違反:
組織は5年前にDKIM鍵を公開し、一度もローテーションしていません。開発者が秘密鍵へのアクセス権を持ったまま退職します。サーバーが鍵の取り消しなしで廃止されます。鍵を含む構成バックアップが保護されていないS3バケットに保存されます。脅威アクターが鍵を見つけ、DMARCを通過する悪意のあるメッセージに署名します。

何が間違い得るか:
DKIM署名は、鍵がローテーションされてもDNSが更新されていない場合、メッセージ本文が転送中に変更された場合、または署名ヘッダーがフォワーダーによって削除された場合に失敗する可能性があります。DKIM通過はDMARC通過を保証しません。アラインメントも必要です。ただし、侵害された鍵からの有効なDKIM署名は、DMARCエンフォースメントを完全にバイパスできます。

予防策:
DKIM鍵を年に一度ローテーションします。サーバーが廃止されたとき、または鍵アクセス権を持つ人員が退職したときに、古い鍵を即座に取り消します。DMARCレポートを通じてDKIM署名の一貫性を監視します。Skysnag Protectを使用して送信者間でのDKIM使用を追跡し、予期しないセレクターからの署名を検出します。

GDPR第32条(1)(d)との関連:
第32条(1)(d)は「処理システムの継続的な機密性、完全性、可用性、および回復力を確保する」措置を要求しています。決してローテーションされない静的鍵は、時間の経過とともに侵害リスクを増加させます。

VI. ギャップ6: メールソースインフラストラクチャへの可視性なし → 未検出の侵害

コンプライアンス違反:
組織はメールを送信していることは知っていますが、ITは代わりに送信するすべてのIPアドレス、ドメイン、またはサービスをリストできません。DMARCレポートが新しいソースを示すとき、それが正当か、不正か、侵害されているかを誰も知りません。調査が始まるまでに数日または数週間が経過します。

何が間違い得るか:
DMARC集約レポートは、エンベロープ送信者(SPFに使用)、ヘッダーFromドメイン(DMARCアラインメントに使用)、およびDKIM署名ドメインを示します。これらのいずれかが期待値と一致しない場合、認証は通過してもスプーフィングは依然として可能です。たとえば、正当なサービスはSPFを通過してもヘッダーFromドメインが異なるためDMARCアラインメントに失敗する可能性があります。監視が認証結果を示しても、ドメインが未認証の使用をブロックするよう受信者に指示していないため、調査がより困難です。

予防策:
承認されたメールインフラストラクチャの完全な在庫を維持します:IPアドレス、送信サービス、SPFインクルード、DKIMセレクター、およびDMARCアラインメントモード。DMARCレポートを毎日在庫と比較します。Skysnag Protectを使用して送信者発見を自動化し、新しいソースにフラグを立て、認証結果を既知のインフラストラクチャと相関させます。

GDPR第30条との関連:
第30条は、組織が「処理活動の記録を維持する」ことを要求しています。メールは処理活動です。ITがメールを送信するシステムとサービスをリストできない場合、記録は不完全です。

VII. ギャップ7: 監視の証拠なし → コンプライアンスを実証できない

コンプライアンス違反:
組織はメールセキュリティを監視していると主張しますが、ログもインシデント対応記録も認証レビューの証拠もエンフォースメント決定の文書もありません。侵害が発生したとき、執行当局は積極的監視の証拠を求めます。組織はそれを提供できません。

何が間違い得るか:
GDPR罰則は、意図、過失、および是正対応に基づいてスケールされます。積極的な監視、証拠に基づくエンフォースメント、および文書化されたインシデント対応を実証する組織は、より好意的な扱いを受けます。これらのいずれも実証できない組織は、より高い罰則に直面します。

予防策:
DMARCレポート、認証決定、送信者変更、およびエンフォースメントアクションをログに記録します。データ保護ポリシーに従ってログを保持します(無期限保持を避けます)。エンフォースメントステージング決定を文書化します。Skysnag Complyを使用して、ドメインと送信者間でのメール認証制御の証拠を維持し、コンプライアンスレビューのための監査証跡を提供します。

GDPR第5条(2)および第24条との関連:
第5条(2)は、組織が「コンプライアンスを実証できる」ことを要求しています。第24条は「適切な技術的および組織的措置」とそれらを「実証する能力」を要求しています。メール認証監視はその証拠を提供します。

VIII. GDPRが実際に要求するもの(要求しないもの)

GDPRはDMARCを名指しで義務付けていません。SPF、DKIM、BIMI、または特定のメール認証プロトコルを指定していません。要求するのは:

第32条: 「リスクに適したセキュリティレベルを確保するための適切な技術的および組織的措置。」
第5条(1)(f): 処理は「不正または違法な処理」に対する「適切なセキュリティ」を確保する必要があります。
第24条: 管理者は「適切な技術的および組織的措置を実装し」、「処理がこの規則に従って実行されていることを実証できる」必要があります。

メール認証制御はこれらの目標をサポートします。執行当局がスプーフィング、不正な送信者アクセス、またはメールベースのデータ流出が被害に寄与した侵害を調査する際、組織が合理的な予防措置を実装したかどうかを評価します。DMARCエンフォースメントがなく、送信者監視がなく、認証ログがないドメインは、合理的措置のより弱い証拠を提示します。

積極的な監視、ステージングされたエンフォースメント、送信者在庫の維持、および文書化されたインシデント対応を実証できる組織は、より強力なコンプライアンス体制を示します。Skysnag Complyを使用して、ドメイン、事業単位、およびサードパーティ送信者間でその証拠を維持します。

IX. 重要なポイント

GDPRはDMARCを義務付けてはいませんが、メール認証管理は第32条、第5条(1)(f)、および第24条のセキュリティ目標をサポートします。
4億ユーロ以上のGDPR罰金は、メールセキュリティのギャップが不正アクセスやデータ流出に寄与した侵害に関連しています。
GDPR制裁決定に現れる最も一般的な7つのメールセキュリティギャップは次のとおりです:(1)ドメイン認証なし、(2)監視されていないサードパーティ送信者、(3)レポート収集のない静的DMARC、(4)強制ポリシーなし、(5)DKIM ローテーションなし、(6)メールインフラストラクチャへの可視性なし、(7)監視の証拠なし。
認証に合格しても受信トレイへの配信は保証されません。認証に失敗しても常に拒否されるわけではありません。しかし、強制措置は規制当局が評価できる測定可能な管理を提供します。
プロアクティブな監視、段階的な強制措置、文書化されたインシデント対応を実証する組織は、侵害調査中により好意的な扱いを受けます。
Skysnag Protectを使用して、正規の送信者を特定し、不正なソースを検出し、サブドメインと送信者グループごとにDMARC強制措置を段階的に実施します。
Skysnag Complyを使用して、コンプライアンス審査のためのメール認証管理、送信者インベントリ、強制措置決定の証拠を維持します。

SkysnagでDMARC監視を開始し、無料のDMARCレコードを取得してください: