ベースラインが何を証明するのかを定義する
認証ベースラインは、意図された構成の承認された説明と、特定の時点でそれをサポートする証拠です。これは、単なるDNSエディタのスクリーンショット、必要なレコードのリスト、または今後のすべてのメールが認証されるという主張ではありません。有用なベースラインは、ドメイン、送信サービス、レコードの所有権、予想される認証パス、および検証基準を結び付けます。バージョン管理により変更が説明可能になります。レビューでは、意図した構成が依然としてビジネスに適合するかどうかを判断します。
この記事では、ベースラインと変更管理のワークフローを提案します。リポジトリの作成、構成のエクスポート、 DNSレコードの編集、メッセージのテストは行われませんでした。プロトコル参照は、構成が何を意味するかを確立しますが、バージョン管理プロセスは、標準が特定のツールを義務付けるという主張ではなく、編集上の運用上の推奨事項です。ベースラインは、実際の観察が収集されるまで、現在の生産動作の証明とは別にしておかなければなりません。
記録の前にアイデンティティと責任を把握する
送信ワークフローごとに、ビジネス目的、ドメイン所有者、サービス オペレーター、表示される From ドメイン、予想されるエンベロープ ID、および DKIM ドメインに署名する。変更を承認できる人、および変更を実行できる人を特定します。 DNS管理者は公開を制御し、サプライヤーは署名を制御し、ビジネス所有者は送信ストリームが存在すべきかどうかを決定できます。これらの責任は、1 つの曖昧な「所有者」フィールドに圧縮されるべきではありません。
RFC 9989 定義する DMARCのドメイン調整関係。したがって、ベースラインでは、そのパスのみを記録するのではなく、意図した位置合わせされたパスを特定する必要があります。 SPF またはDKIMが有効になっています。 RFC 6376 DKIM署名を定義し、 セレクタ モデル。重要なセレクターとパブリック ルックアップの依存関係を記録しますが、秘密署名キー、API シークレット、または回復資格情報を一般的な構成ベースラインに配置しないでください。
完全な関連レコードセットを保存する
ゾーンと権威プロバイダーを使用して、観察された正確なDNS所有者名、タイプ、完全な値、TTL を記録します。プロバイダーとエディターの表記を、公開されたDNS表現とは別にしてください。 TXTデータの場合、1 レコード内の複数の文字列と、1 つのセット内の複数のレコードを区別します。選択された 1 つの行を示すスクリーンショットでは、他の値が省略されている可能性があり、必ずしも安全な置換操作をサポートするとは限りません。意図した変更を完全に説明するのに十分な構造を保持してください。
Azure DNSレコードのドキュメント レコード セット、 TXT文字列、プロバイダー固有のメタデータについて説明します。これは Azure モデルの有用な証拠であり、すべてのプロバイダーに共通のスキーマではありません。実際のプロバイダーが異なる場合は、ワークシートを適用する前に、現在の表現を確認し、動作を更新してください。ベースラインでは、収集時間と制限のある証拠として元のプロバイダーのエクスポートを保持しながら、中立的な表現を使用できます。
意図された状態と観察された状態を分離する
承認されたターゲット構成と実稼働環境から収集された観察については、個別のセクションを使用します。望ましいSPF値は、権威サーバーがそれを公開したという証拠ではありません。 DNS応答は、プロバイダーが予期されたセレクターを使用してメッセージに署名したことを証明するものではありません。受信メッセージの結果は、すべての送信ワークフローが同じパスを使用していることを証明するものではありません。各観察は、その範囲、時間、収集方法、および対象となる正体を記載する必要があります。
使用するとき Authentication-Results 検証証拠として、信頼境界の懸念事項に従います。 RFC 8601。任意の送信者が伝えるアサーションを受け入れるのではなく、関連する信頼できる受信者からの結果を保持します。編集されたメッセージの証拠と機密性の高いオリジナルは、適切なアクセス制御の下で保管してください。ベースラインは、承認された証拠の場所を参照する必要があり、単に便宜上、機密のメッセージ本文や資格情報を蓄積するものではありません。
それぞれの改訂を説明可能な決定にする
内部バージョン識別子を割り当て、以前に承認されたバージョン、変更理由、意図した差分、影響を受けるワークフロー、リスク評価、ビジネスの承認を記録します。読みやすい diff には、追加、削除、置換が完全なコンテキストで示されている必要があります。サプライヤーが導入されているか、セレクターがローテーションされているか、廃止された送信者が削除されているか、ポリシーが変更されているかを識別する必要があります。書式設定のみの変更によって、承認または認証に対する意味のある変更が隠蔽されないように注意してください。 アライメント.
組織のツールに適したレビュー メカニズムを選択しますが、バージョン管理のコミットが承認と同等であると想定しないでください。意思決定の所有者と承認範囲を個別に記録します。観察された現在の構成が、実行前に予想されるベースラインと異なる場合に何が起こるかを定義します。安全な対応は、準備された変更ファイルが存在するからといって、単に新しい状態を上書きするのではなく、違いを調査して調整することです。
同時編集とロールバック制限を考慮する
Azure DNS 、ゾーンとレコード セットに関連付けられた Etag を文書化し、更新中に指定された場合に同時変更を検出する方法について説明します。これはプロバイダー固有の同時実行メカニズムであり、一般的なDNSプロパティではありません。 TTL はキャッシュ動作を制御しますが、誰が編集できるかは制御しません 記録 または、ある変更が別の変更を上書きするかどうか。実際のインターフェイスの同時実行動作を確認し、承認された変更に使用されたバージョンの証拠を保持します。
ロールバック基準では、技術的なトリガーと権限のある意思決定者の両方を特定する必要があります。復元資料には、以前の完全な構成、関連するプロバイダーの状態、および既知の依存関係が必要です。 DNSレコードを復元しても、削除されたサプライヤー リソースが復元されたり、配信されたメールが元に戻されたり、キャッシュされた回答が即座に置き換えられたりすることはありません。古い値をコピーするとすべての結果が逆転すると約束するのではなく、調整されたワークフローとしてリカバリを計画します。このドラフトの作成においてロールバックは試みられませんでした。
ベースラインレビューワークシート
ベースライン バージョン、ドメインとワークフローの範囲、ビジネス目的、構成所有者、実行所有者、正確なレコード インベントリ、および予想される認証パスを含むワークシートを作成します。日付、既知のギャップ、ソース文書のバージョン、レビュートリガーを含む証拠参照を追加します。提案されたリビジョンには、意図する差分、ビジネスの承認、前提条件、同時実行性チェック、検証基準、ロールバック基準、および最終処理を含めます。観察されていない結果は、完了した設計レビューによって暗示されたままにするのではなく、明示的にマークします。
レビューのトリガーには、新しい送信者、サプライヤーの廃止、ドメインの移行、キーのローテーション、ビジネス所有権の変更、または重要な認証インシデントが含まれます。カレンダーの見直しも役立つかもしれませんが、その頻度は、発明された普遍的な間隔ではなく、組織のリスクと変更の量を反映する必要があります。ベースラインがすべての正当なワークフローをまだカバーしているかどうか、および廃止された依存関係が残っているかどうかを確認します。変更されていないファイルを実稼働環境がドリフトしていない証拠として扱わないでください。
架空の診断: 文書化されていないサプライヤーの追加
架空の組織には、請求サービスと従業員のメールをカバーする承認されたベースラインがあります。その後、マーケティング チームが別のサプライヤーを通じて別の送信者を紹介します。ベースラインは変更されませんが、準備されたDNSクリーンアップにより、新しいサービスが使用する依存関係が削除されます。提案された演習では、レビュー担当者はクリーンアップを承認する前に、現在の所有権およびワークフローの記録をベースラインと比較し、文書化のギャップを発見します。
チームは新しいワークフローを調整し、ビジネスの承認を得て、意図した差分を更新し、承認された変更後に検証証拠を収集します。以前に承認されたからといって、やみくもに古いベースラインを復元することはありません。このシナリオは架空のものです。サプライヤーは検出されず、構成の差分も適用されず、配信テストも行われませんでした。これは、バージョン履歴を現在の所有権および運用上の観察と組み合わせる必要がある理由を示しています。
制限を可視化した状態でベースラインを解放する
有用なレビューの結論には、どのワークフローが対象となっているか、どの観察結果がそれを裏付けているか、何が未検証のままであるかが記載されています。普遍的な配信や永続的な安全性を保証するものではありません。認証制御は正しくても、コンテンツ、評判、アカウント侵害、受信者ポリシーがメールの結果に影響を与える可能性があります。将来のオペレーターが構成記録を完全なセキュリティ評価と間違えないように、ベースラインによってこれらの境界が見えるようにする必要があります。
カタログには、ベースライン、意図した差分、ビジネス承認、検証、およびロールバック基準を含む変更レコードが必要です。その元の運用記録は未公開のままです。このドラフトは提案された構造を提供するものであり、実行された変更の証拠を提供するものではありません。専門家によるレビュー、ソースの適用性、生産ルート、視覚的なアクセシビリティ、および所有者の公開も未解決のままです。公開可能なバージョンには、実際の観察と承認を伴う承認されたサンプルが必要であり、秘密を暴露することなく適切に編集および保持されます。