[ SPF ]

ビジネスユニット全体でSPF依存関係登録を維持する

SPF構文、外部依存関係、および責任あるビジネス オーナーを接続するレジスターを構築します。

EmailAuth研究チームによる · 3 分で読めます

【ポイント】

  • ポリシーのスナップショット、コンシューマ、依存関係エッジをまとめて保持します。
  • 単なる静的なグラフではなく、入力に依存する評価パスを保持します。
  • レジスターを使用して、共有の変更と退職を安全に決定します。
このページでは

アン SPF dependency register answers a practical question: if this DNS value changes or this provider disappears, which business mail is affected and who can decide what to do?トップレベルのコピー TXTレコード その質問に単独で答えることはできません。依存関係はネストされ、組織の外部で制御され、特定の入力に対してのみ到達する場合があります。

ポリシーとその利用者をモデル化する

使用中のSMTPドメインごとに、正確なDNS所有者名、現在のレコード、キャプチャ時刻、ゾーン所有者、および変更プロセスを含む 1 つのポリシー エントリを作成します。その ID を使用するアプリケーションとビジネス ユニットを接続します。 From ドメインを別のフィールドに表示しておくと、 SPFルックアップ ID と間違われることがなくなります。親ドメインの SPFレコード 子に自動的に継承されません。 RFC 7208 §2.4, RFC 7208 §4.

インクルード、リダイレクト、その他の DNS に依存する用語ごとにエッジを追加し、ターゲットとその制御者を識別します。 Include and redirect are not interchangeable: an include matches when its recursive check returns pass, while redirect delegates evaluation when the current policy reaches that modifier's conditions.スナップショット内の用語の順序と修飾子を保持します。 RFC 7208 §5.2, RFC 7208 §6.1.

行動するために十分な証拠を保管する

推奨される登録フィールドは次のとおりです。 ポリシー ドメイン。ビジネスサービス。ビジネスオーナー。技術所有者。プロバイダーアカウントの参照。依存関係のターゲット。許可の理由。代表的な送信 IP。通常のエンベロープ ドメインとフェイルオーバー エンベロープ ドメイン。スナップショットの日付。評価されたパスの結果。次の見直しを提案。そして退職条件。資格情報と秘密キーを登録に入れないでください。内部アカウントの参照を適切なレビュー担当者に制限します。

動的マクロの場合は、式と代表的な展開値の両方を記録します。入力 ID、IP、および時間がない平坦化された依存関係図は、完全な評価トレースではありません。 SPF 's DNS-query-causing term limit applies during evaluation, including recursive checks, so one path can reach a problem that another path avoids. RFC 7208 §4.6.4, RFC 7208 §7.

レジスターをチーム全体で活用できるようにする

例示的な例: 調達と顧客サポートはどちらも、同じ組織ポリシーを通じて_spf.service.example.netに依存しています。調達側は契約終了を計画しており、削除を要求している。依存関係レジスタは、共有インクルードが削除される前にサポート サービスを公開します。この決定は、未確認のDNSクリーンアップではなく、サービスの廃止または分離になります。

各消費者に対するビジネス責任を維持しながら、共有の変更を調整するために 1 人の技術ポリシー所有者を割り当てます。所有者を追加して証拠をテストするためのオンボーディング、依存関係を更新するための移行、残りのコンシューマーを解決するためのオフボーディングが必要です。これは運用上の推奨事項であり、追加のSPFプロトコル要件ではありません。

スコアを追うのではなく変更を確認する

スナップショットの差分を取得して、新しいターゲット、削除された権限、拡大された範囲、および変更されたルックアップ パスを検出します。コンテキストの変化を調査します。プロバイダーは合法的にインフラストラクチャをローテーションする可能性があります。現在のファーストパーティの指示と受信メッセージの証拠を使用して、影響の大きい変更を検証します。古い状態と決定をアーカイブし、 DNS変更が成功した後にレジスタを更新します。

A useful completion test is a tabletop exercise: choose one dependency and identify every affected service, the decision owner, the test route and the rollback path.チームがそれを行うことができない場合、現在のすべてのSPFチェックに合格したとしても、レジスタには依然としてギャップが残ります。

具体的な意思決定記録を使用する

共有プロバイダーの例では、依存関係に 2 つのコンシューマー エントリ (調達とサポート) を指定し、所有者と終了条件を分けます。サポートが残っている間に調達が終了した場合、共通のポジティブ インクルードを削除することはまだ正当化されません。分離を提案する前に、現在のポリシー、用語修飾子、代表的な IP/エンベロープ入力、およびネストされたターゲットのスナップショットをキャプチャします。この例は、完了した在庫監査ではなく、決定を示しています。

[ 取り除く ]

ポリシーのスナップショット、コンシューマ、依存関係エッジをまとめて保持します。 Preserve input-dependent evaluation paths, not just a static graph.レジスターを使用して、共有の変更と退職を安全に決定します。

【役割別】

これがあなたにとって何を意味するか

実際の次のステップに向けて、自分の役割を選択してください。

IT / メール管理者

キャプチャ時刻を含むポリシーのスナップショットを保持します。

生のスナップショットを読み取り可能な依存関係エッジと並べて保持します。将来の調査者が、パスが健全であるとみなされた理由を説明できるように、代表的な評価入力を記録します。

次のステップ

  1. キャプチャ時刻を含むポリシーのスナップショットを保持します。
  2. ネストされた用語と代表的な入力をマッピングします。
  3. 移行のたびにコンシューマーを更新します。

CISO / SecOps

外部で制御されているDNS依存関係を特定します。

レジスタを使用して、外部制御と孤立したアクセス許可を識別します。秘密を漏らし、内部サービスとアカウントの詳細にアクセス制御を適用します。

次のステップ

  1. 外部で制御されているDNS依存関係を特定します。
  2. 所有されていない送信権限を確認します。
  3. 内部アカウントの参照を適切に制限します。

創業者 / 非技術系

共有ビジネスメールの所有者を特定します。

登録者がインシデント コール内で障害が発生したビジネス サービスの所有者を特定できるかどうかを尋ねます。その価値は、行数ではなく、より迅速な意思決定とより安全なリタイアによってもたらされます。

次のステップ

  1. 共有ビジネスメールの所有者を特定します。
  2. サービスのオンボーディングに登録を含めます。
  3. レビュー中に依存関係から影響への参照を実行します。

[ よくある質問 ]

よくある質問

TXT レコードのエクスポートは依存関係レジスタですか?

これは有用な入力ですが、ビジネス コンシューマー、所有権、およびネストされた依存関係が欠けています。

在庫の最小単位は何ですか?

SMTPで使用される実際のSPFポリシー ドメイン。アプリケーションと所有者に接続されます。

RFC 7208 §2.3 RFC 7208 §2.4

各ビジネスユニットは共有SPFポリシーを編集する必要がありますか?

明確な変更プロセスを備えた調整された技術所有者を使用します。部門は、矛盾する編集を行うのではなく、ビジネス要件を承認する必要があります。

マクロはどのように表現すべきでしょうか?

Retain the macro expression and representative expanded targets with the inputs used. 1 つの拡張で考えられるすべてのトラフィックをカバーするつもりはありません。

RFC 7208 §7

なぜ評価されたパスを保存するのでしょうか?

Short-circuit evaluation and recursion affect which terms are reached.静的なグラフだけでは特定の結果を説明できません。

RFC 7208 §4.6.2 RFC 7208 §4.6.4 RFC 7208 §5.2

複数のチームにサービスを提供することはできますか?

はい。 Record every consumer before removing or replacing the shared permission.

どれくらいの頻度で見直すべきでしょうか?

リスクベースの頻度を選択し、オンボーディング、移行、プロバイダーの変更、退職時にも更新します。 RFC はビジネス レビューの間隔を規定していません。

レジスターが使用可能であることを証明するものは何ですか?

レビュー担当者は依存関係を選択し、その利用者、所有者、証拠、テスト手順、安全な変更パスを特定できます。

[ 情報源 ]

情報源

  1. RFC 7208

    セクション §2.3 · §2.4 · §4 · §4.6.2 · §4.6.4 · §5.2 · §6.1 · §7

  2. RFC 9989

    セクション §4.4

[ 用語集 ]

用語集

SPF
接続 IP および関連するSMTP ID の認可評価。

RFC 7208 §2.4

ID からのメール
リバース パスが null の場合に、定義された postmaster/ HELO構造を使用してSPFによって使用されるSMTPエンベロープ ID。

RFC 7208 §2.4

DMARCアラインメント
認証された識別子と作成者ドメインの間に必要な関係。

RFC 9989 §4.4

SPFを含む
再帰的評価。その合格結果がインクルードメカニズムと一致するものとします。その後、 include 修飾子によって外側の結果が決まります。

RFC 7208 §5.2

企業の来歴

一流の金融機関と政府が選ばれる理由 電子メール セキュリティ ダッシュボードを廃止しました。

従来の電子メール認証プラットフォームはダッシュボードを販売し、エンジニアに作業を依頼します。一か八かの環境では、手動による監視は適用の遅れ、構成のドリフト、および監視されていないシャドウ ドメインを意味します。

EmailAuthは、エージェントの電子メール来歴プラットフォームです。 当社のエージェントが執行します p=reject、サードパーティの送信者を調整し、ドメインを完全に移動します。 RFC 9989 新しいDMARC標準に準拠し、人間による監査機能を備えています。

政府 大企業 ティア1金融機関

SaaS · 専用テナント · エアギャップオンプレミス · BYOK 暗号化

ナレッジベース