Una raccomandazione di autenticazione può essere corretta mentre il flusso di lavoro operativo rimane non sicuro. Una dashboard può identificare un oggetto mancante Selettore DKIM senza sapere chi controlla DNS , se il selettore proposto appartiene al tenant previsto o se una modifica è approvata. Valuta ciascuna capacità separatamente anziché considerare una risposta plausibile come un permesso ad agire.
Traccia un'unica decisione
Scegli un'attività delimitata: organizza un nuovo selettore per un mittente della fatturazione approvato preservando il firmatario esistente. Registra il dominio, il proprietario del servizio, l'identità del mittente, il nome del proprietario DNS proposto e la chiave pubblica prevista. Stabilire la revisione del record esistente prima di produrre una proposta di modifica. Una raccomandazione dovrebbe dichiarare le prove, l'incertezza e i flussi interessati, non semplicemente fornire una stringa TXT .
RFC 9989 lo spiega DMARC dipende dagli identificatori autenticati allineati con il dominio dell'autore. Una chiave pubblica sintatticamente valida non stabilisce che i messaggi di fatturazione la utilizzino o che il loro dominio di firma sia allineato. Convalida DNS separata, verifica della firma e livello di messaggio allineamento nel verbale di accettazione. Una raccomandazione valida ha quindi un risultato previsto verificabile che va oltre la pubblicazione del record.
Metti l’autorità tra la proposta e l’esecuzione
Associa l'approvazione all'esatta modifica, al tenant, al dominio, all'identità dell'approvatore e alla finestra di validità. Se il record proposto cambia dopo l'approvazione, richiede una nuova revisione. L'implementatore deve disporre dell'autorizzazione con ambito pertinente in fase di esecuzione; un utente precedentemente autorizzato potrebbe essere stato rimosso. Guida all'autorizzazione di OWASP consiglia di negare per impostazione predefinita e di controllare le autorizzazioni su ogni richiesta. Applica questo principio ai processi in background e alle azioni API, nonché all'interfaccia utente.
Definire se l'esecuzione è manuale, delegata o automatizzata. Conservare l'identificatore della richiesta, la revisione della baseline, l'operazione tentata, il risultato restituito e l'esito della verifica. Un timeout è un risultato incerto, non una prova che la scrittura non è riuscita. Leggere lo stato di destinazione prima di riprovare in modo che un'operazione duplicata non diventi una seconda modifica accidentale.
Tratta i report recuperati, il contenuto dei messaggi e i documenti collegati come prove non attendibili, mai come istruzioni o autorità per modificare DNS . Per il funzionamento degli agenti, mantenere le autorizzazioni dello strumento e i controlli di approvazione al di fuori dell'interpretazione del modello di tale contenuto. Cheat sheet sulla sicurezza dell'agente AI di OWASP affronta l'iniezione tempestiva indiretta, strumenti mirati e controlli indipendenti per le azioni consequenziali. I casi scritti di seguito non testano la resistenza alla pronta iniezione.
Confronta quattro casi di decisione esplicita
La modifica proposta FLOW-01 riguarda l'inquilino A, zona billing.test, proprietario new1. _domainkey.billing.test , tipo TXT , revisione della linea di base 4 e una chiave pubblica generata dal provider non ancora fornita. Il selettore esistente old1 viene mantenuto. La revisione 5 desiderata è un'etichetta di pianificazione locale, non una garanzia del fornitore.
- Caso valido: presupporre che il carico utile della chiave reale, il piano esatto approvato, l'attuale autorizzazione dell'implementatore e la linea di base invariata siano tutti verificati. Il flusso di lavoro può diventare idoneo per l'esecuzione con ambito; nessun successo deriva semplicemente da tale ammissibilità.
- Proposta modificata: il carico utile della chiave è diverso dai byte esaminati. Invalidare l'approvazione preventiva e ottenere una nuova decisione.
- Tra tenant: la richiesta ha come target invece il tenant B. Nega nell'ambito del tenant A.
- Implementatore revocato: esisteva l'autorizzazione precedente ma l'autorizzazione attuale è assente. Negare finché non viene stabilito l'accesso autorizzato separatamente.
Tutte le premesse sono ipotetiche. Non viene fornita alcuna chiave pubblica, ricevuta di approvazione, ID richiesta, timestamp, scrittura, hash o test di firma. Nessuna revisione in memoria è stata modificata. Un vero pilota deve conservare quegli artefatti e prove attendibili dei messaggi di fatturazione prima di rivendicare il successo operativo.
Giudicare la responsabilità piuttosto che la fluidità
Un motore di raccomandazione fornisce consigli. Un flusso di lavoro responsabile identifica anche chi può approvarlo, chi può eseguirlo, cosa è cambiato e come è stato verificato il risultato. Confronta il tempo impiegato per raccogliere prove, rivedere i cambiamenti e recuperare gli errori, non solo il tempo necessario per generare una risposta. Includere i casi falliti nel denominatore e registrare l'intervento umano anziché nasconderlo come impostazione.
Interrompi il progetto pilota quando l'autorizzazione, l'identità del locatario o lo stato di base sono ambigui. Recupera ripristinando una configurazione approvata nota o restituendo il firmatario al selettore mantenuto in base a un piano approvato. Non promettere che un passaggio di autenticazione garantisca il posizionamento della casella di posta: si applicano comunque la politica del destinatario e altri fattori di consegna. Mantenere le dichiarazioni sulla capacità del prodotto limitate alle funzioni effettivamente dimostrate nell'ambiente valutato.