API ベースのセキュリティ ツールは、送信署名者または受信SMTPゲートウェイにならずにメールボックスのコンテンツを検査できます。その存在によってあなたの情報が公開されることはありません SPF ポリシー、許可する DKIM 署名者または確立者 DMARC アライメント。すべてのルートの保護として説明する前に、ツールがどのメッセージ集団をいつ認識するか、またどのようなアクションを実行できるかを文書化します。
対象範囲とタイミングを定義する
受信パスと送信パスを別々に描画します。配信後にメッセージを読み取るアプリケーションは、既にメールボックスに到達したコンテンツを検出または修復する場合があります。これはSMTP時の防止を実証するものではありません。送信アプリケーション メールは、監視対象のメールボックスをまったく通過しない場合があります。メールボックスのスコープ、フォルダー、アクセス許可、ポーリングまたは通知の動作、および予想される処理遅延を検証する実装プロパティとして記録します。
Microsoft Graph メッセージ デルタ v1.0 は、バージョン管理されたメールボックス インターフェイスの具体的な例であり、完全なセキュリティ製品ではありません。そのドキュメントでは、メッセージ コレクションと継続リンクの変更追跡が定義されています。 メッセージデルタAPI。 API サーフェスとアダプターのリビジョンを固定して、後の変更をデータ内のインシデントと区別できるようにします。
作業を中断せずに継続状態を追跡します
返された次ページ URL は、トークンを再構築するのではなく、不透明な継続として使用します。現在の変更が永続的に処理された後でのみ、次のラウンドのために最終的なデルタ URL を保存します。 グラフのページング。期限切れまたは無効な継続状態に対する回復戦略を維持します。再起動は、黙って中断のないカバレッジとしてカウントされてはなりません。
冪等性には操作固有のキーが必要です。メッセージ ID のみを永久に重複排除すると、同じメッセージに対する本物の更新が破棄される可能性があります。再生されたイベントと、後の変更や削除を区別します。別のコレクションにトークンが適用されるのを避けるために、チェックポイントを使用してメールボックスとフォルダーのスコープを記録します。これらはアダプター設計の推奨事項であり、Graph がユニバーサル イベント リビジョン フィールドを提供すると主張するものではありません。
仮説的な継続台帳を設計する
作成された 2 つのページに m1 リビジョン 1 と m2 リビジョン 1 が含まれており、その後に m1 リビジョン 1、m2 リビジョン 2 の再生、および m3 の削除マーカーが続くとします。リビジョンはローカルな教育分野であり、約束されたグラフ プロパティや推奨される運用重複排除アルゴリズムではありません。意図された決定は、m1 の同じ効果の再生を回避し、後の m2 状態を保持し、アプリケーションの保持ルールに基づいて m3 の削除を処理することです。実際のアダプターは、実際の API コントラクトからキーを定義する必要があります。
別の仮想バッチでは、リクエスト A は成功を返し、B は Retry-After:3 で 429 を返し、C は 403 を返します。 A を完了としてマークし、B を文書化された遅延より早くスケジュールし、C を盲目的に再試行するのではなく許可調査のためにブロックしたままにします。 Retry-After が存在しない場合、Microsoft は指数バックオフを推奨します。これらの文書化されたケースでは、リクエスト、スリープ、バッチ実行、データベースのコミット、またはクラッシュ回復テストは実行されませんでした。
部分的な障害を明示的に処理する
バッチ内に配置されたリクエストを含む、個々のリクエスト レベルでのスロットル ドキュメントをグラフ化します。受け入れられたバッチ エンベロープを普遍的な成功として解釈するのではなく、各サブ応答を検査します。文書化された Retry-After 遅延を使用し、即時の再試行ループを回避します。 スロットリング そして JSONバッチ処理.
最後に正常に処理されたウィンドウ、保留中の再試行、およびブロックされた権限エラーを監視します。承認されたアクセスと保持を使用して、セキュリティ目的に必要なメッセージ データのみをエクスポートします。正常な API 接続は、すべてのメッセージが検査されたことを証明するものではなく、検査が完了しても修復が成功したことを証明するものではありません。
アウトバウンド認証受け入れテストを独立させます。実際に承認された最終メッセージ、その署名およびエンベロープ ID、および信頼できる受信結果を検査します。クローズ API と認証は別個の証拠で機能します。これらの書面による決定は計画を支援するものです。テナントのアクセス許可、実際のページング、回復、応答アクション、送信メールの検証は、完了した結果ではなく展開テストのままです。
処理が不完全な場合にチェックポイントを保持する
最終ページに未解決の書き込みエラーが含まれているとします。デルタリンクに進むと、アプリケーションの次のラウンドでコミットされていない変更が隠蔽される可能性があります。不完全な作業を回復可能な状態に保ち、テストされた耐久性のある処理戦略によって問題が解決されるまで、カバレッジのギャップを記録します。これはアダプター設計のアドバイスであり、トークンを保持するだけで回復がアトミックになることを保証するものではありません。メッセージ デルタは、指定されたフォルダーを追跡します。選択したメールボックスとフォルダーの範囲が、意図したセキュリティ ワークロードをどのようにカバーするかを文書化します。
ソースと実行境界
RFC 9989セクション 4.4、5.3.5、および 5.4 認証、調整、処理を区別する。パスはメッセージの内容を保証するものではありません。ここでの運用上の決定は、範囲を絞った推奨事項と明確に仮説的な例であり、顧客、プロバイダー、または過去の設備の新しいテストではありません。実際の変更には、独自に承認された範囲、保持された証拠、および責任ある決定が必要です。