Identificare quale servizio Microsoft riceve il messaggio
La "posta ospitata da Microsoft" non identifica una politica di inoltro universale. Inizia stabilendo se la destinazione è un'organizzazione Microsoft 365 , un account Outlook .com consumer o un percorso che passa attraverso un altro servizio di sicurezza prima di raggiungere una casella di posta Microsoft. I controlli amministrativi e le prove disponibili in un ambiente non dovrebbero essere considerati validi per un altro.
Questo flusso di lavoro usa la documentazione corrente Microsoft 365 per la posta gestita dall'organizzazione e richiede la verifica del percorso effettivo. Si tratta di una proposta di indagine e di piano di modifica, non di un rapporto attestante che le impostazioni del locatario sono state ispezionate o modificate. Innanzitutto ottenere un confronto diretto/inoltrato, quindi scegliere la modifica più piccola che risolva il fallimento dimostrato preservando i controlli di sicurezza dell'organizzazione.
Individuare il confine in cui è cambiata l'autenticazione
Disegna il percorso dal mittente originale attraverso ogni forwarder o gateway fino al servizio ricevente. Per ciascun confine, registrare l'host di connessione, disponibile mittente della busta, Dominio dell'autore, DKIM firme e trasformazioni osservate. Distinguere un intermediario di terze parti in entrata da Exchange Online che inoltra la posta in uscita. Sono casi operativi diversi anche quando entrambi si verificano all'interno della stessa conversazione.
SPF utilizza la fonte di connessione finale per l'identità valutata lì, quindi l'autorizzazione della fonte originale potrebbe non descrivere la connessione di inoltro. RFC 7208 sezione 10.3 spiega questa limitazione. Un analista non dovrebbe modificare il mittente originale Registro SPF fino a quando non saranno comprese l'identità interessata e l'autorizzazione prevista.
Confronta le firme originali e finali utilizzando RFC 6376. La modifica del contenuto di un gateway può invalidare una firma quando successivamente viene modificato il materiale coperto canonicalizzazione. Si tratta di una condizione, non di un'affermazione secondo cui tutte le intestazioni aggiunte o tutte le regole di inoltro distruggono DKIM . Conserva le copie grezze dei messaggi laddove autorizzato in modo che l'ipotesi possa essere testata anziché dedotta da un diagramma del fornitore.
Leggi i risultati Microsoft senza rinominarli
Quello di Microsoft panoramica dell'autenticazione distingue SPF , DKIM e DMARC dall'autenticazione composita, registrata come compauth. Quest'ultimo incorpora una valutazione aggiuntiva. Mantieni ciascun campo e l'azione di gestione finale in colonne separate. Un passaggio composito non deve essere riscritto nella registrazione dell'incidente come un normale passaggio DMARC .
Il corrente guida affidabile sul sigillante ARC descrive l'utilizzo delle valutazioni precedenti degli intermediari legittimi e fornisce un esempio diagnostico con compauth=pass e reason=130 mentre dmarc=fail rimane visibile. Avverte inoltre che altri filtri possono ancora agire. Questa è un'interpretazione specifica del fornitore da verificare nei risultati attendibili generati dal destinatario, non una promessa che gli stessi campi appaiano in ogni account.
Non fidarti di un arbitrario Authentication-Results linea semplicemente perché è vicino alla parte superiore di un'intestazione incollata. Stabilire quale sistema ricevente ha generato il risultato e come viene identificato il confine attendibile. Se è disponibile solo uno screenshot o un estratto estratto, registrare la provenienza mancante e richiedere un campione completo opportunamente redatto attraverso la procedura approvata.
Mantenere distinte le decisioni SRS e ARC
Quello di Microsoft Documentazione SRS riguarda gli scenari di inoltro e inoltro applicabili e separa esplicitamente il MAIL FROM riscritto dal From visibile. Documenta anche le eccezioni. Non dare per scontato che ogni messaggio che entra in Microsoft 365 riceva la stessa riscrittura o tratti un'uscita SRS comportamento come correzione per un gateway in entrata non correlato.
Una busta riscritta può supportare SPF per il dominio di riscrittura senza allineamento all'autore originale. La relazione di dominio pertinente è ancora richiesta da RFC 9989 sezione 4.4. ARC trasmette invece valutazioni di autenticazione precedenti che il destinatario deve prendere in considerazione. RFC 8617 sezione 7.2.1 descrive l'uso della policy locale, non la sostituzione automatica del risultato dell'autenticazione ordinaria.
Qualsiasi proposta di fidarsi di un sigillatore è una decisione di sicurezza. Identificare l'esatto servizio legittimo, la sua necessità operativa e un approvatore responsabile; mantenere i criteri di configurazione e rimozione precedenti. Non aggiungere un'ampia fiducia semplicemente perché un messaggio trasporta un set ARC sintatticamente valido. Il corrente Progetto di riclassificazione ARC è un lavoro in corso, mentre RFC 8617 rimane Sperimentale a questa data di revisione.
Modifica del gateway immaginario con un test di accettazione limitato
In questo esempio fittizio, i servizi di esempio ricevono la posta tramite un gateway di contenuti prima di una cassetta postale Microsoft 365 . Un campione diretto inventato verifica un campione allineato Firma DKIM; un esempio equivalente instradato tramite gateway ha un allegato riscritto e non verifica più quella firma. Lo scenario presuppone tali osservazioni esclusivamente per spiegare l'indagine. Non è stato effettuato l'accesso a nessun tenant o messaggio.
Il proprietario determinerà innanzitutto se la trasformazione è necessaria e se è supportata una configurazione meno dirompente. Se venisse proposto un trattamento basato su ARC, la revisione richiederebbe l’effettiva identità del sigillatore, prove autenticate della catena e una specifica approvazione da parte del locatario. I criteri di accettazione registrerebbero separatamente l'autenticazione ordinaria, i risultati compositi, i filtri di sicurezza e le disposizioni. Il semplice aspetto della casella di posta non dimostrerebbe il meccanismo previsto.
I criteri di recupero dovrebbero includere una fiducia inaspettatamente ampia, nuove classificazioni errate o la mancata conservazione delle prove richieste. Il piano di rollback dovrebbe identificare l'esatta configurazione approvata, non semplicemente istruire qualcuno a disabilitare l'elaborazione della sicurezza fino all'arrivo dei messaggi.
Chiudi solo il percorso verificato
Dopo una modifica autorizzata, confrontare i nuovi campioni diretti e indiretti con la linea di base attraverso i messaggi rappresentativi. Conserva la versione delle impostazioni, i timestamp e qualsiasi incertezza residua del fornitore o del tenant. Un percorso di lavoro attraverso un gateway non convalida tutte le regole di inoltro nell'organizzazione.
Il cancello delle prove originali è invariato e visibile: campioni di consegna diretta e indiretta con percorso, busta, firme e risultati attendibili confrontati. Qui non sono incluse prove operative, approvazione del locatario, test in tempo reale o esecuzione del ripristino. Il risultato finale è una procedura rivedibile con distinzioni supportate dall'origine, non una correzione Microsoft 365 completata.