Fai domande a cui è possibile rispondere con prove
Un questionario di autenticazione aziendale dovrebbe collegare i requisiti aziendali al comportamento supportato, alla responsabilità operativa e alle prove di accettazione. Un lungo elenco di domande sulle funzionalità sì o no può nascondere importanti limitazioni: un fornitore può supportare un'ampia categoria senza supportare lo specifico tenant, ciclo di vita o comportamento di implementazione di cui l'acquirente ha bisogno. Il questionario dovrebbe quindi chiedere cosa è supportato, in quale configurazione, chi lo gestisce e come è possibile verificare la risposta.
Questo articolo propone una struttura di questionario e non afferma che EmailAuth implementa alcuna funzionalità elencata. Nessun fornitore è stato contattato e non è stata ottenuta alcuna risposta al questionario. Linee guida sulla responsabilità condivisa di Microsoft E Linee guida sull'identità multi-tenant di Azure fornire esempi ufficiali di distinzioni importanti, ma non possono sostituire le prove attuali del prodotto da valutare.
Inizia con l’ambito e la proprietà delle decisioni
Registra la popolazione di clienti proposta, i domini, i flussi di lavoro di invio, l'opzione di distribuzione, le integrazioni richieste e gli amministratori previsti. Identificare quali requisiti sono obbligatori, quali sono preferenze e quali necessitano di un revisore legale, di sicurezza o commerciale qualificato. Un questionario senza un ambito definito può produrre risposte tecnicamente vere per un'edizione o un ambiente diverso. Conserva la versione del prodotto e offri il riferimento insieme a ciascuna risposta.
Chiedere al fornitore di distinguere il supporto implementato, il supporto dipendente dalla configurazione, il lavoro pianificato e i requisiti non supportati. Non trasformare una data della roadmap in una capacità attuale. Laddove una risposta dipenda da un altro servizio, identificare tale dipendenza e la parte responsabile. L'acquirente dovrà inoltre documentare i propri obblighi; un fornitore non può dimostrare un flusso di lavoro completo se le decisioni DNS , all'identità o all'accesso del cliente richiesto rimangono indefinite.
Coprire identità, ruoli e confini dell'inquilino
Chiedi come si autenticano gli utenti, come le identità sono legate ai tenant e come vengono assegnate le autorizzazioni a domini, report, esportazioni e operazioni amministrative. Le linee guida sull'identità di Azure distinguono l'autenticazione dall'autorizzazione basata sul ruolo o sulle risorse e dai diritti commerciali. Riflettete queste distinzioni in domande separate. Una dichiarazione secondo cui SSO è supportato non stabilisce l'isolamento del cliente o l'effetto di una riduzione del ruolo su una sessione esistente.
Includere domande sulle identità dei servizi, sul ciclo di vita degli utenti, sull'accesso al supporto dei fornitori e sulle prove di audit. Richiedere una spiegazione aggiornata del comportamento di disabilitazione e revoca anziché presupporre che un'integrazione di provisioning gestisca ogni percorso di accesso. Richiedere test sintetici negativi autorizzati che dimostrino che un inquilino non può leggere, esportare o modificare le risorse di un altro inquilino. Uno screenshot del prodotto o un elenco di ruoli da solo non fornisce tale prova.
Chiedere come vengono ottenute le osservazioni sull'autenticazione
Documentare quali fonti vengono acquisite dalla piattaforma, come viene descritta la loro copertura e come vengono rappresentate le osservazioni non supportate o mancanti. RFC 9990 definisce DMARC reporting aggregato, che dispone di un proprio processo di rilevamento e distribuzione dei report. La capacità di una piattaforma di analizzare i report non garantisce che ogni destinatario li invii o che ogni mittente legittimo sia rappresentato in un periodo.
Chiedere in che modo il prodotto preserva la provenienza originale del report, gestisce i duplicati e spiega i limiti di interpretazione. Se combina eventi di consegna del provider con report di autenticazione, chiedi quali identificatori consentono il collegamento e se le conclusioni sono a livello di messaggio o di flusso. Non richiedere una garanzia di consegna universale dai dati di autenticazione. Il questionario dovrebbe rendere visibili i confini di osservazione del prodotto piuttosto che incoraggiare affermazioni non supportate di copertura completa.
Chiarire le responsabilità operative e di distribuzione
Chiedi quali opzioni di distribuzione sono attualmente supportate e cosa include ciascuna. Definisci chi applica patch all'infrastruttura, aggiorna l'applicazione, gestisce le identità, monitora l'acquisizione, esegue il ripristino e gestisce gli incidenti. Il quadro di responsabilità condivisa di Microsoft illustra perché gli obblighi variano in base al modello di servizio, ma il fornitore effettivo deve fornire la propria allocazione supportata. Una risposta contrassegnata come condivisa dovrebbe descrivere il proprietario del trasferimento e della verifica, non semplicemente dividere una casella di controllo tra due parti.
Per le opzioni private o dedicate, chiedi informazioni separatamente sui percorsi di rete, sulla gestione dei dati, sull'accesso al supporto e sulle dipendenze esterne. Non dedurre l'isolamento da un'etichetta di architettura. Richiedere prove dei limiti pertinenti e ipotesi trasparenti del carico di lavoro per il dimensionamento. Il questionario stesso non dovrebbe autorizzare un'implementazione, una modifica del firewall o un trasferimento di dati; tali azioni richiedono un lavoro di implementazione approvato separato.
Includere la gestione dei dati e i requisiti di audit
Chiedi quali dati vengono conservati, dove li collocano le configurazioni supportate, chi può accedervi e come funzionano la conservazione, l'eliminazione e l'esportazione. Distinguere dati primari, log, backup e artefatti di supporto. Questo articolo non determina la conformità legale né afferma il comportamento di residenza di un fornitore. Il proprietario qualificato appropriato dovrebbe rivedere i requisiti contrattuali e normativi utilizzando le prove attuali.
Per la verificabilità, chiedere quali azioni vengono registrate, se sono inclusi i tentativi negati, come sono rappresentati il contesto dell'attore e del tenant e chi può esportare o modificare le impostazioni di conservazione. Documentazione del registro di controllo di Microsoft Entra è un esempio di descrizione ufficiale del registro delle attività, non una prova della copertura di un altro prodotto. Richiedere campioni e limiti specifici del prodotto anziché accettare la parola audit come risposta completa.
Rendere trasparenti il carico di lavoro e le ipotesi commerciali
Dichiara i domini, i tenant, gli utenti previsti, il volume dei report, la cadenza di conservazione e integrazione utilizzando input organizzativi approvati. Segna chiaramente stime e incognite. Un mese parziale di osservazioni potrebbe non supportare una previsione esatta del carico di lavoro annuale. Chiedi al fornitore quali variabili influenzano il preventivo e come vengono conteggiate le modifiche, ma non dedurre prezzi o inclusioni del pacchetto dalla documentazione tecnica.
Mantenere l'inclusione commerciale separata dall'accettazione tecnica. Una funzionalità può essere inclusa in un'offerta ma richiedere comunque configurazione e prova; una caratteristica dimostrata potrebbe non rientrare nel pacchetto proposto. Registrare la validità, l'ambito e le esclusioni del preventivo solo quando esiste un preventivo approvato. Nessun prezzo, sconto, modello di costo o raccomandazione di approvvigionamento viene prodotto da questo manoscritto.
Un foglio di lavoro con requisiti e prove
Crea colonne per requisito, motivo aziendale, priorità, configurazione supportata, risposta del fornitore, fonte di prova, revisore, test di accettazione, limitazione e decisione. Aggiungi un registro delle ipotesi con input, fonte, data, confidenza e impatto se errato. Collegare ciascun requisito obbligatorio a un elemento di prova concreto piuttosto che a un'ampia pagina di marketing. Conserva le domande senza risposta come lacune invece di interpretare il silenzio come supporto.
Per i controlli testabili, descrivere l'apparecchio autorizzato e il risultato atteso. Per gli impegni contrattuali individuare il relativo accordo approvato. Per le responsabilità operative, identificare il proprietario nominato e trasferirlo. Questi tipi di prove possono completarsi a vicenda ma non dovrebbero essere sostituiti indiscriminatamente. Un contratto può attribuire la responsabilità senza dimostrare una prova tecnica; un test riuscito può mostrare il comportamento senza creare un impegno di supporto.
Diagnosi fittizia: un questionario dall'aspetto completo
Un acquirente immaginario riceve risposte affermative per SSO, esportazioni, distribuzione privata e registri di controllo. La revisione inizialmente segna il completamento del questionario. Un secondo revisore chiede quale edizione supporta tali funzionalità, se le esportazioni preservano i limiti del tenant e cosa succede a una sessione attiva dopo la disabilitazione. Le risposte originali non risolvono queste domande perché descrivono categorie piuttosto che risultati.
La risposta proposta è quella di richiedere prove mirate e lasciare aperti i requisiti interessati fino alla revisione. L'acquirente non è tenuto ad accusare il fornitore di false dichiarazioni; il questionario potrebbe semplicemente essere stato troppo vago. Questo scenario è fittizio e non descrive alcuna risposta effettiva del fornitore o lacuna di prodotto. Non è stata eseguita alcuna comunicazione o test esterno.
Pubblicare le lacune con la raccomandazione
Una valutazione utile identifica i requisiti supportati, le limitazioni accettate, le prove irrisolte e le ipotesi sul carico di lavoro che potrebbero modificare la decisione. Dovrebbe essere leggibile sia dai proprietari tecnici che da quelli aziendali senza far crollare le loro diverse responsabilità. Evitare un punteggio numerico che implichi una precisione oltre l’evidenza, a meno che il suo metodo e i suoi limiti non siano esplicitamente approvati.
Il catalogo richiede una matrice di requisiti e prove e ipotesi trasparenti sul carico di lavoro o sui costi. Quei manufatti originali rimangono aperti. Rimangono aperti anche la revisione da parte di specialisti umani, l’applicabilità della fonte, i percorsi di produzione, l’accessibilità e il rilascio del proprietario. Questa bozza fornisce una struttura e un esercizio fittizio, non una due diligence del fornitore completata o un'affermazione delle capacità EmailAuth .