欧州の組織がメールドメインを保護するためにDMARCを導入する際、DMARCプロバイダーの選択は単なる技術的決定ではありません。
データガバナンス、ベンダーリスク、国際データ移転の決定にもなり得ます。
DMARCレポートは、認証ステータス以上の情報を明らかにすることがあります。ドメインの代わりにどのシステムがメールを送信しているか、どのベンダーが関与しているか、どこで認証が失敗しているか、どのIPアドレスがアクティブか、地域をまたいでメールがどのように流れているか、不正な送信試行がどこで発生している可能性があるかを示すことがあります。
EU組織にとって、この情報はGDPR、契約上のデータ保護義務、セクター固有の規則、および内部データレジデンシーポリシーの観点から関連する可能性があります。
米国のCLOUD法は、この評価にさらなる層を追加します。
CLOUD法は、対象となる米国サービスプロバイダーに対し、データが米国外に保存されている場合でも、その所有、保管、または管理下にある特定のデータを保存、バックアップ、または開示することを要求できます。米国を拠点とする、または米国に管理されている技術プロバイダーを使用するEU組織にとって、これはセキュリティテレメトリーをサードパーティプラットフォームにルーティングする前に評価すべき法的および管轄権の問題を生じさせる可能性があります。
これは、EU企業が米国を拠点とするプロバイダーを使用できないという意味ではありません。
しかし、どのようなデータが処理されているか、どこに保存されているか、どの法的移転メカニズムが適用されるか、どのような保護措置が講じられているか、政府のアクセス要求がどのように処理されるかを理解する必要があります。
DMARC保護とデータ保護は、別々の会話として扱われるべきではありません。
それらは同じ信頼アーキテクチャの一部です。
免責事項: この記事は一般的な情報を提供するものであり、法的助言とみなされるべきではありません。組織は、特定のコンプライアンス要件、移転評価、規制義務について、資格のある法律顧問に相談する必要があります。
I. この文脈におけるCLOUD法の意味
2018年に制定された米国のCLOUD法は、特定の米国サービスプロバイダーが、データが米国内外のどこに保存されているかにかかわらず、その所有、保管、または管理下にあるデータを開示するよう要求される可能性があることを明確にしました。
DMARCサービスについて、関連する問題はプロバイダーがヨーロッパにデータを保存しているかどうかだけではありません。
より深い問題は次のとおりです。
誰がサービスを管理し、誰がデータにアクセスでき、どの法制度がプロバイダーに適用される可能性があるか?
これが重要なのは、DMARCプロバイダーが防御者と攻撃者の両方にとって有用な運用セキュリティテレメトリーを処理する可能性があるためです。
実装によっては、DMARCプロバイダーは次のものを処理する可能性があります:
- DMARC集約レポート
- DMARC障害またはフォレンジックレポート(有効な場合)
- 送信IPアドレス
- 認証結果
- SPF、DKIM、DMARCアライメントデータ
- メール量のパターン
- サードパーティ送信者情報
- ドメイン設定
- ユーザーアカウントおよび管理者データ
- レポートから導出されたセキュリティ分析
- 履歴的な実施およびポリシーデータ
この情報は、特に集約レポートでは、必ずしもメッセージの内容を含むわけではありません。しかし、組織のメールインフラストラクチャに関する機密性の高い運用の詳細を明らかにする可能性があります。
そのため、プロバイダーの選択は、セキュリティとプライバシーの両方のレンズを通して評価されるべきです。
II. DMARCレポートデータが機密情報となり得る理由
DMARCレポートは、しばしば技術的なログと説明されます。
この説明は不完全です。
DMARCデータは、組織がどのようにメールを送信しているか、どのプラットフォームが承認されているか、どのベンダーが誤設定されているか、どのドメインが完全に保護されていないか、どこでスプーフィング試行が発生しているかを明らかにすることができます。
たとえば、DMARC集約データは次のことを示す可能性があります:
- どのIPアドレスがドメインの代わりに送信しているか
- トランザクションメールにどのプロバイダーが使用されているか
- どのマーケティングプラットフォームがアクティブか
- どの内部システムがメールを送信しているか
- どのソースがSPFまたはDKIMアライメントに失敗しているか
- どのサードパーティが適切に設定されていないか
- どのサブドメインが露出しているか
- どの受信プロバイダーが認証失敗を見ているか
この情報は、セキュリティチームにとって価値があります。
攻撃者にとっても価値がある可能性があります。
したがって、成熟したDMARCプログラムは、レポートデータを無害なメタデータとして扱うことを避けるべきです。セキュリティテレメトリーとして管理されるべきです。
III. GDPRと国際データ移転
EU組織にとって、個人データが欧州経済領域外で処理または移転される場合、GDPRが関連します。
GDPR第V章は、有効な移転メカニズムが適用されない限り、第三国への個人データの移転を制限しています。これらのメカニズムには、十分性決定、必要な補完的措置を伴う標準契約条項、拘束的企業準則、またはGDPRで認められているその他のメカニズムが含まれる場合があります。
Schrems II判決は、第三国の監視または合法的アクセス制度の対象となるプロバイダーへの移転に関する精査を強化しました。それ以来、組織は契約だけでなく、移転を取り巻く法的環境と実際の保護措置も評価することが期待されています。
2023年に採択されたEU-米国データプライバシーフレームワークは、認証された米国組織に対する十分性メカニズムを提供しています。ただし、組織は、プロバイダーが認証されているか、関連する処理が対象となっているか、特定のユースケースに対して追加の契約上または技術上の保護措置が必要かどうかを確認する必要があります。
DMARCプロバイダーの選択において、実用的な評価には次のものが含まれるべきです:
- DMARCレポートデータは個人データ、セキュリティテレメトリー、またはその両方か?
- データはどこに保存されているか?
- データはどこで処理されているか?
- どのエンティティがアクセスできるか?
- プロバイダーはEUを拠点としているか、米国を拠点としているか、またはより広い企業グループの一部か?
- 国際移転が行われているか?
- どの移転メカニズムが適用されるか?
- 標準契約条項または別のメカニズムが整っているか?
- 補完的措置が必要か?
- どの保存期間が適用されるか?
- フォレンジックレポートはデフォルトで無効になっているか?
- プロバイダーは政府のアクセス要求をどのように処理するか?
この評価は、特に規制された組織や厳格なデータレジデンシー義務を持つ企業の場合、文書化されるべきです。
IV. CLOUD法は自動的に非準拠を意味するわけではない
問題を過度に単純化することを避けることが重要です。
米国を拠点とするプロバイダーを使用することは、自動的にGDPR非準拠を意味するわけではありません。
EUデータセンターを使用することは、自動的にすべての管轄リスクを排除するわけではありません。
コンプライアンスの問題は、完全な文脈に依存します:
- プロバイダーの法的構造
- データ処理場所
- データアクセス制御
- 暗号化モデル
- 契約上の保護措置
- 移転メカニズム
- 政府アクセスポリシー
- 透明性報告
- データ最小化の実践
- 保存制限
- データに対する顧客の制御
- EU外でサポートまたはエンジニアリングアクセスが発生するかどうか
真剣な評価は、サーバーがホストされている国だけでなく、完全な運用モデルを見ます。
V. EU企業が検討すべきDMARCプロバイダーのリスク領域
DMARCプロバイダーを選択または検討する際、EU組織はいくつかの領域を評価する必要があります。
VI. 1. 法的構造
契約エンティティが誰であるかを理解します。
EUを拠点とするベンダー、米国を拠点とするベンダー、米国グループのEU子会社は、異なる法的および運用上の考慮事項を提示する可能性があります。
尋ねるべき質問:
- どの法人がサービスを提供しているか?
- どのエンティティがデータ処理契約に署名するか?
- どのエンティティが顧客データにアクセスできるか?
- サポート、エンジニアリング、またはセキュリティ運用はEU外で実行されるか?
- プロバイダーは米国の合法的アクセス規則の対象か?
- サブプロセッサーが関与しているか?
答えは、ベンダーリスクレビューで文書化されるべきです。
VII. 2. データレジデンシーと処理場所
データレジデンシーは重要ですが、正確に理解されるべきです。
プロバイダーは、サポートや分析アクセスが他の場所で発生する一方で、EUにデータを保存する場合があります。別のプロバイダーは、EU請求やEU契約を提供しながら、EU外でレポートを処理する場合があります。
尋ねるべき質問:
- DMARCレポートはどこに保存されているか?
- レポートはどこで解析および分析されているか?
- バックアップはどこに保管されているか?
- ログはどこに保存されているか?
- 管理者はデータ処理をEUに制限できるか?
- プロバイダーは非EUサブプロセッサーを使用しているか?
- サポートアクセスには国境を越えたアクセスが必要か?
目標は、マーケティングの主張だけでなく、実際のデータパスを理解することです。
VIII. 3. DMARCレポートの種類
すべてのDMARCデータが同じ機密性を持っているわけではありません。
集約レポートは、一般的にフォレンジックまたは障害レポートよりも侵襲性が低いです。集約レポートには通常、認証結果と送信元情報が含まれます。障害レポートには、受信者の実装に応じてメッセージレベルのデータが含まれる場合があります。
EU組織にとって、最も安全なデフォルトは次のとおりです:
- 監視には
rua=を通じた集約レポートを使用する。 - プライバシー、法務、セキュリティチームが承認しない限り、
ruf=を通じたフォレンジックレポートを避ける。 - データ最小化と保存制限を適用する。
- 認証と実施に必要以上のものを収集しない。
障害レポートは、主要な受信者の間で採用が限られており、追加のプライバシーと保存義務を生じさせる可能性があります。軽率に有効にすべきではありません。
IX. 4. アクセス制御
DMARCプラットフォームは、内部ユーザーに機密テレメトリーを公開する可能性があります。
組織は次のことを検討すべきです:
- ロールベースのアクセス制御
- 管理者権限
- MFA要件
- 監査ログ
- APIアクセス制御
- セッション制御
- エクスポート権限
- サポートアクセス手順
- 顧客間の分離
セキュリティテレメトリーは、ガバナンスなしに広くアクセス可能であるべきではありません。
X. 5. 政府アクセスと透明性
EU組織は、プロバイダーが合法的アクセス要求をどのように処理するかを理解する必要があります。
尋ねるべき質問:
- プロバイダーは透明性レポートを公開しているか?
- プロバイダーは法的に許可されている場合に顧客に通知するか?
- プロバイダーは過度にまたは違法な要求に異議を唱えるか?
- プロバイダーはサブプロセッサーを開示しているか?
- プロバイダーはEU顧客データに影響を与える要求をどのように処理するかを説明しているか?
- 契約上の通知義務が含まれているか?
これはすべてのリスクを排除するものではありませんが、透明性と説明責任を向上させます。
XI. 6. 保存と削除
DMARCテレメトリーが長く保持されるほど、露出面は大きくなります。
組織は次のことを確認する必要があります:
- デフォルトの保存期間
- 顧客が設定可能な保存
- バックアップ削除のタイムライン
- エクスポートおよび削除の権利
- ログ保存ポリシー
- アカウント終了削除プロセス
保存は運用ニーズに合わせるべきです。
多くの組織にとって、生のDMARCテレメトリーの無期限保存は不要です。
XII. DPIAと移転影響評価
EU組織は、DMARCプロバイダーを導入する際に、データ保護影響評価または移転影響評価が適切かどうかを検討する必要があります。
これは特に次の場合に関連します:
- DMARCデータが第三国のプロバイダーにルーティングされる。
- 組織が規制されたセクターで運営している。
- プロバイダーがEEA外でデータを処理する。
- 障害レポートが有効になっている。
- ドメインが機密コミュニケーションに使用される。
- プロバイダーが詳細な運用セキュリティテレメトリーにアクセスできる。
- 顧客または従業員のコミュニケーションパターンが推測される可能性がある。
実用的な評価は次のことをカバーする必要があります:
- どのようなデータが収集されるか
- なぜデータが必要か
- データに個人データが含まれているか
- どの移転メカニズムが適用されるか
- どのような保護措置が講じられているか
- どのサブプロセッサーが関与しているか
- データはどれくらい保持されるか
- 誰がデータにアクセスできるか
- 政府のアクセス要求はどのように処理されるか
- 侵襲性の低い代替手段が利用可能か
目的は、それ自体のために書類を作成することではありません。
目的は、データフローを防御可能にすることです。
XIII. リスクを軽減する技術的保護措置
法的保護措置は重要ですが、技術的保護措置も同様に重要です。
EU組織は、次のことをサポートするDMARCプロバイダーを探すべきです:
- EUデータレジデンシーオプション
- データ最小化
- 転送中および保存時の暗号化
- 強力なアクセス制御
- MFA実施
- 監査ログ
- 顧客管理の保存
- 制限されたサポートアクセス
- サブプロセッサーの透明性
- 安全なレポート取り込み
- テナント間の分離
- 明確な削除手順
- APIセキュリティ制御
これらの保護措置は露出を減らし、防御可能性を向上させます。
単一の保護措置だけではCLOUD法やGDPR移転の問題を解決しません。強さは、契約上、技術上、組織上、ガバナンス上の制御の組み合わせから生まれます。
XIV. DMARCデータの運用ガバナンス
DMARCは、1回限りのDNSプロジェクトとして扱われるべきではありません。
継続的なガバナンスプログラムの一部であるべきです。
組織は次のものを維持する必要があります:
- ドメインインベントリ
- 送信者インベントリ
- DMARCレポート宛先レコード
- プロバイダーリスク評価
- データ処理契約
- 該当する場合の移転評価
- サブプロセッサーレビュー
- 保存決定
- アクセス制御レビュー
- インシデント対応手順
- 変更管理記録
- 監視と修復の証拠
この文書化は、DMARCデータが単にアウトソーシングされるのではなく、積極的に管理されていることを証明するのに役立ちます。
XV. DMARCプロバイダーに尋ねるべき質問
DMARCプロバイダーを選択または更新する前に、EU組織は次のことを尋ねるべきです:
- どの法人がサービスを提供しているか?
- DMARCレポートデータはどこに保存されているか?
- DMARCレポートデータはどこで処理されているか?
- どのサブプロセッサーが使用されているか?
- 処理をEUに制限できるか?
- 顧客データはEU外のサポートまたはエンジニアリングチームによってアクセスされるか?
- データがEEAを離れる場合、どの移転メカニズムが適用されるか?
- 必要な場合、標準契約条項が利用可能か?
- 該当する場合、プロバイダーはEU-米国データプライバシーフレームワークの下で認証されているか?
- フォレンジックレポートはデフォルトで無効になっているか?
- デフォルトのデータ保存期間は何か?
- 保存期間を短縮できるか?
- どのようなアクセス制御が利用可能か?
- 監査ログは利用可能か?
- プロバイダーは透明性レポートを公開しているか?
- プロバイダーは法的に許可されている場合、政府のアクセス要求を顧客に通知するか?
- 終了後、データはどのように削除されるか?
- 顧客はデータをエクスポートできるか?
- バックアップはどのように処理されるか?
- プロバイダーはEU重視の展開要件をサポートしているか?
これらの質問は、曖昧なデータレジデンシーの議論を実用的なベンダー評価に変えるのに役立ちます。
XVI. DMARCプロバイダーがEUまたは非EUかどうかを確認する
多くのEU企業は、DMARCレポートがどこに送信されているかを知りません。
ドメインにDMARCが有効になっている可能性がありますが、レポート宛先が非EUプロバイダー、古いベンダー、管理されていないメールボックス、または法務、セキュリティ、コンプライアンスチームによってレビューされたことのないサードパーティプロセッサーを指している可能性があります。
これが重要なのは、多くのDMARCプロバイダーがEUを拠点としていないためです。
EU組織にとって、DMARCプロバイダーの場所と法的構造は、ベンダーリスクレビューの一部であるべきです。
DMARCレポートは次のことを明らかにすることができます:
- 承認された送信者
- メールフロー
- 認証失敗
- サードパーティベンダー
- ドメイン保護のギャップ
- 不正な送信試行
そのデータは盲目的にルーティングされるべきではありません。
Skysnagのスキャナーを使用して、DMARCレポート宛先がEUまたは非EUプロバイダーを指しているかどうかを確認してください:
スキャナーは、現在のDMARCレコードとレポート宛先を特定するのに役立つため、チームはプロバイダーがGDPR、データレジデンシー、および内部コンプライアンスの期待と一致しているかどうかを確認できます。
公開スキャンは、完全な法的または移転評価に代わるものではありません。しかし、DMARC設定がより深いレビューに値するかどうかを迅速に示すことができます。
XVII. Skysnag Protectがどのように役立つか
Skysnag Protectは、組織がメール認証データの可視性と制御を維持しながらDMARCを実装するのを支援します。
EU組織にとって、Skysnag Protectは、次のようなコンプライアンス重視の制御でDMARC実装をサポートできます:
- DMARC監視
- 送信者の識別
- 不正なソースの検出
- SPFおよびDKIMアライメントの可視性
- 実施準備の追跡
- MTA-STSおよびTLS-RPTサポート
- セキュリティおよびコンプライアンスチームへのレポート
- DMARCテレメトリーのデータガバナンスサポート
- 必要に応じた欧州データレジデンシーオプション
目的は、DMARCレコードを公開するだけではありません。
目的は、セキュリティ、プライバシー、コンプライアンスの期待をサポートする制御されたメール認証プログラムを構築することです。
組織は、ここでSkysnag Protectについて詳しく知ることができます:
XVIII. 重要なポイント
米国のCLOUD法はDMARC法ではなく、特定のDMARC要件を作成するものではありません。
ただし、EU組織が米国を拠点とする、または米国に管理されている技術プロバイダーを使用してDMARCレポートデータを処理する場合、関連する可能性があります。
DMARCレポートは、送信者、ベンダー、認証失敗、メールフロー、ドメイン保護のギャップを含む、機密性の高い運用セキュリティテレメトリーを明らかにすることができます。
EU組織は、GDPR、ベンダーリスク、移転、データガバナンスのレンズを通してDMARCプロバイダーを評価する必要があります。
重要なレビュー領域には次のものが含まれます:
- 法的構造
- データレジデンシー
- 処理場所
- サブプロセッサー
- 移転メカニズム
- アクセス制御
- 保存
- フォレンジックレポート
- 政府アクセスポリシー
DMARC集約レポートは通常デフォルトであるべきです。フォレンジックレポートは、法務、プライバシー、セキュリティのレビュー後にのみ有効にすべきです。
米国を拠点とするプロバイダーを使用することは自動的に非準拠を意味するわけではなく、EUデータセンターを使用することは自動的にすべてのリスクを排除するわけではありません。完全な運用モデルが重要です。
成熟したDMARCプログラムは、ドメインを保護しながら、その保護によって作成されるデータも制御する必要があります。
EU組織にとって、正しい質問は次のとおりではありません:
「DMARCはあるか?」
より強力な質問は次のとおりです:
「DMARCデータがどこに行くか、誰がアクセスできるか、その処理が法的およびコンプライアンス義務の下で防御可能かどうかを知っているか?」
あなたがEU企業である場合、DMARCレポートがどこに送信されているかを確認することから始めてください。Skysnagのスキャナーを使用して、現在のDMARCプロバイダーがEUまたは非EUと思われるかどうかを確認してください:
