Faça perguntas que possam ser respondidas com evidências
Um questionário de autenticação empresarial deve conectar os requisitos de negócios ao comportamento suportado, à responsabilidade operacional e às evidências de aceitação. Uma longa lista de perguntas sobre recursos do tipo sim ou não pode ocultar limitações importantes: um fornecedor pode oferecer suporte a uma categoria ampla, mas não oferece suporte ao inquilino, ao ciclo de vida ou ao comportamento de implantação específico que o comprador precisa. O questionário deve, portanto, perguntar o que é suportado, em que configuração, quem o opera e como a resposta pode ser verificada.
Este artigo propõe uma estrutura de questionário e não afirma que EmailAuth implementa qualquer recurso listado. Nenhum fornecedor foi contatado e nenhuma resposta ao questionário foi obtida. Orientação de responsabilidade compartilhada da Microsoft e Diretrizes de identidade multilocatário do Azure fornecem exemplos oficiais de distinções importantes, mas não podem substituir as evidências atuais do produto que está sendo avaliado.
Comece com o escopo e a propriedade da decisão
Registre a população proposta de clientes, domínios, fluxos de trabalho de envio, opção de implantação, integrações necessárias e administradores pretendidos. Identifique quais requisitos são obrigatórios, quais são preferências e quais precisam de um revisor jurídico, de segurança ou comercial qualificado. Um questionário sem escopo definido pode produzir respostas tecnicamente verdadeiras para uma edição ou ambiente diferente. Preserve a versão do produto e ofereça referência ao lado de cada resposta.
Peça ao fornecedor para distinguir suporte implementado, suporte dependente de configuração, trabalho planejado e requisitos não suportados. Não transforme a data do roteiro em capacidade atual. Quando uma resposta depender de outro serviço, identifique essa dependência e a parte responsável. O comprador também deve documentar as suas próprias obrigações; um fornecedor não pode demonstrar um fluxo de trabalho completo se as decisões necessárias DNS , identidade ou acesso do cliente permanecerem indefinidas.
Cubra identidade, funções e limites do locatário
Pergunte como os usuários são autenticados, como as identidades são vinculadas aos locatários e como as permissões são atribuídas a domínios, relatórios, exportações e operações administrativas. A orientação de identidade do Azure distingue a autenticação da autorização baseada em funções ou de recursos e de direitos comerciais. Reflita essas distinções em questões separadas. Uma declaração de que há suporte para SSO não estabelece o isolamento do cliente ou o efeito de uma redução de função em uma sessão existente.
Inclua perguntas sobre identidades de serviço, ciclo de vida do usuário, acesso ao suporte do fornecedor e evidências de auditoria. Exija uma explicação atual do comportamento de desabilitação e revogação, em vez de presumir que uma integração de provisionamento lida com todos os caminhos de acesso. Solicite testes sintéticos negativos autorizados que demonstrem que um locatário não consegue ler, exportar ou alterar os recursos de outro locatário. Uma captura de tela do produto ou uma lista de funções por si só não fornece essa evidência.
Pergunte como as observações de autenticação são obtidas
Documente quais fontes a plataforma ingere, como sua cobertura é descrita e como as observações não comprovadas ou ausentes são representadas. RFC 9990 define DMARC relatórios agregados, que possuem seu próprio processo de descoberta e entrega de relatórios. A capacidade de uma plataforma de analisar relatórios não garante que todos os destinatários os enviem ou que todos os remetentes legítimos sejam representados num período.
Pergunte como o produto preserva a proveniência do relatório original, lida com duplicatas e explica os limites de interpretação. Se combinar eventos de entrega do provedor com relatórios de autenticação, pergunte quais identificadores permitem a ligação e se as conclusões são no nível da mensagem ou no nível do fluxo. Não solicite uma garantia de entrega universal de dados de autenticação. O questionário deve tornar visíveis os limites de observação do produto, em vez de encorajar alegações não fundamentadas de cobertura completa.
Esclareça as responsabilidades operacionais e de implantação
Pergunte quais opções de implantação são suportadas atualmente e o que cada uma inclui. Defina quem corrige a infraestrutura, atualiza o aplicativo, gerencia identidades, monitora a ingestão, executa a recuperação e trata de incidentes. A estrutura de responsabilidade compartilhada da Microsoft ilustra por que as obrigações variam de acordo com o modelo de serviço, mas o fornecedor real deve fornecer sua própria alocação suportada. Uma resposta marcada como compartilhada deve descrever o proprietário da transferência e da verificação, e não apenas dividir uma caixa de seleção entre duas partes.
Para opções privadas ou dedicadas, pergunte separadamente sobre caminhos de rede, manipulação de dados, acesso de suporte e dependências externas. Não infira isolamento a partir de um rótulo de arquitetura. Exija evidências dos limites relevantes e suposições transparentes de carga de trabalho para dimensionamento. O questionário em si não deve autorizar implantação, alteração de firewall ou transferência de dados; essas ações exigem um trabalho de implementação aprovado e separado.
Incluir requisitos de manipulação de dados e auditoria
Pergunte quais dados são retidos, onde as configurações suportadas os colocam, quem pode acessá-los e como funcionam a retenção, a exclusão e a exportação. Distinguir dados primários, logs, backups e artefatos de suporte. Este artigo não faz uma determinação de conformidade legal nem afirma o comportamento de residência de um fornecedor. O proprietário qualificado apropriado deve analisar os requisitos contratuais e regulamentares utilizando evidências atuais.
Para auditabilidade, pergunte quais ações são registradas, se as tentativas negadas estão incluídas, como o contexto do ator e do locatário é representado e quem pode exportar ou alterar as configurações de retenção. Documentação do log de auditoria do Microsoft Entra é um exemplo de descrição oficial de registro de atividades, não uma prova da cobertura de outro produto. Exija amostras e limites específicos do produto, em vez de aceitar a palavra auditoria como uma resposta completa.
Torne a carga de trabalho e as suposições comerciais transparentes
Indique os domínios, locatários, usuários, volume de relatórios, retenção e cadência de integração esperados usando informações organizacionais aprovadas. Marque estimativas e incógnitas com clareza. Um mês parcial de observações pode não apoiar uma previsão exata da carga de trabalho anual. Pergunte ao fornecedor quais variáveis afetam a cotação e como as alterações são contabilizadas, mas não deduza preços ou inclusões de pacotes a partir da documentação técnica.
Mantenha a inclusão comercial separada da aceitação técnica. Um recurso pode estar incluído em uma oferta, mas ainda assim exigir configuração e evidências; um recurso demonstrado pode estar fora do pacote proposto. Registre a validade, o escopo e as exclusões da cotação somente quando existir uma cotação aprovada. Nenhum preço, desconto, modelo de custo ou recomendação de aquisição é produzido por este manuscrito.
Uma planilha de requisitos e evidências
Crie colunas para requisitos, motivos comerciais, prioridade, configuração suportada, resposta do fornecedor, fonte de evidências, revisor, teste de aceitação, limitação e decisão. Adicione um registro de suposição com entrada, fonte, data, confiança e impacto se estiver errado. Vincule cada requisito obrigatório a um item de evidência concreto, em vez de a uma ampla página de marketing. Retenha as perguntas não respondidas como lacunas em vez de interpretar o silêncio como apoio.
Para controles testáveis, descreva o dispositivo autorizado e o resultado esperado. Para compromissos contratuais, identifique o acordo aprovado relevante. Para responsabilidades operacionais, identifique o proprietário nomeado e a transferência. Estes tipos de provas podem complementar-se, mas não devem ser substituídos indiscriminadamente. Um contrato pode atribuir responsabilidades sem demonstrar um teste técnico; um teste bem-sucedido pode mostrar comportamento sem criar um compromisso de apoio.
Diagnóstico fictício: um questionário completo
Um comprador fictício recebe respostas afirmativas para SSO, exportações, implantação privada e registros de auditoria. A revisão inicialmente marca o questionário como concluído. Um segundo revisor pergunta qual edição oferece suporte a esses recursos, se as exportações preservam os limites do locatário e o que acontece com uma sessão ativa após a desativação. As respostas originais não resolvem essas questões porque descrevem categorias em vez de resultados.
A resposta proposta é solicitar evidências do escopo e deixar os requisitos afetados em aberto até serem revisados. O comprador não precisa acusar o fornecedor de declarações falsas; o questionário pode simplesmente ter sido demasiado vago. Este cenário é fictício e não descreve nenhuma resposta real do fornecedor ou lacuna do produto. Nenhuma comunicação externa ou teste foi realizado.
Publique as lacunas com a recomendação
Uma avaliação útil identifica requisitos suportados, limitações aceites, provas não resolvidas e pressupostos de carga de trabalho que podem alterar a decisão. Deve ser legível por proprietários técnicos e empresariais, sem prejudicar suas diferentes responsabilidades. Evite uma pontuação numérica que implique precisão além da evidência, a menos que seu método e limitações sejam explicitamente aprovados.
O catálogo requer uma matriz de requisitos e evidências e carga de trabalho ou suposições de custos transparentes. Esses artefatos originais permanecem abertos. A revisão de especialistas humanos, a aplicabilidade da fonte, as rotas de produção, a acessibilidade e a liberação do proprietário também permanecem em aberto. Este rascunho fornece uma estrutura e um exercício fictício, não uma due diligence concluída do fornecedor ou uma afirmação dos recursos EmailAuth .