Compre um limite de controle evidenciado
Uma plataforma de autenticação pode anunciar funções, registros de auditoria e isolamento de locatários, mas esses rótulos não estabelecem como os controles se comportam nos fluxos de trabalho pretendidos pelo comprador. Uma avaliação de compras deve perguntar quem pode ler, exportar, alterar e administrar quais dados de clientes, como as mudanças no ciclo de vida afetam o acesso e quais evidências registram essas ações. Uma demonstração bem-sucedida por parte de um administrador não é um teste negativo de acesso não autorizado.
Diretrizes de identidade multilocatário do Azure distingue autenticação, autorização e direitos comerciais. Use essas distinções para estruturar as perguntas do comprador, em vez de assumir que uma função de login abrange todos os recursos e ações. Este artigo é uma estrutura de requisitos, não uma afirmação de que EmailAuth ou outra plataforma nomeada implementa os controles propostos. Nenhum inquilino foi acessado, nenhuma permissão foi alterada ou nenhum produto foi adquirido.
Defina primeiro a matriz de acesso do comprador
Liste as funções esperadas de usuários e serviços, relacionamentos de inquilinos e recursos antes de revisar os nomes das funções de um fornecedor. Inclua configuração de domínio, relatórios de autenticação, dados brutos, exportações, integrações, administração de usuários e configurações comerciais quando relevante. Para cada combinação, indique se a leitura, criação, modificação, exclusão ou exportação deve ser permitida. O limite pretendido pelo comprador é a referência contra a qual o comportamento do produto pode ser avaliado.
Não presuma que “somente leitura” exclui a exportação ou que “administrador de inquilino” está confinado a um inquilino sem provas. As equipes de serviços compartilhados podem precisar legitimamente de vários clientes, enquanto os usuários de clientes individuais devem ver apenas o escopo aprovado. Registre essas exceções explicitamente. Um papel amplo aceito para um teste não deve se tornar silenciosamente o projeto de acesso à produção. Exija que o fornecedor mapeie as funções reais para a matriz do comprador e identifique distinções não suportadas.
Verifique a vinculação do locatário além da interface
Um inquilino seletor ou um item de navegação oculto não é prova suficiente de isolamento. A identidade autenticada deve ser autorizada para o recurso solicitado no limite do lado do servidor. Os requisitos devem abranger leituras diretas, pesquisas, exportações, gravações e trabalhos em segundo plano, incluindo referências a recursos pertencentes a outro locatário. Use fixtures sintéticas com dados visivelmente diferentes para que um resultado acidental entre inquilinos seja detectável.
A orientação do Azure alerta que a configuração incorreta da federação pode conceder acesso a inquilinos não intencionais. A revisão deve, portanto, incluir como as identidades são associadas aos locatários, quem pode alterar essa associação e como um usuário pertencente a vários locatários seleciona o escopo. Não infira a propriedade apenas a partir de um sufixo de e-mail nem presuma que um identificador de locatário fornecido pelo cliente autoriza seu uso. O próprio fornecedor deve explicar e demonstrar o seu modelo suportado.
Pergunte o que o log de auditoria realmente registra
Documentação do log de auditoria do Microsoft Entra descreve registros de atividades para mudanças nesse ambiente de identidade. É um exemplo útil de modelo oficial de registro de auditoria e não uma evidência de que outra plataforma registra os mesmos eventos. Um comprador deve solicitar o catálogo exato de eventos do produto, definições de campo, controles de acesso, comportamento de retenção e opções de exportação relevantes para seus próprios requisitos.
Pergunte se os registros identificam suficientemente o ator, o alvo, a ação, o tempo, o resultado e o contexto do inquilino para investigar uma mudança. Distinguir a atividade do usuário da atividade de identidade de serviço e as ações bem-sucedidas das tentativas negadas. Não presuma que todas as tentativas de autorização malsucedidas são registradas apenas porque aparecem alterações administrativas. Da mesma forma, um log que mostra que uma solicitação foi enviada pode não mostrar se a alteração resultante foi concluída. Exija exemplos reais com dados confidenciais redigidos e limitações declaradas.
Revise o acesso e a integridade do log como controles
Um log de auditoria pode conter informações confidenciais de clientes e de identidade. Defina quem pode visualizá-lo, pesquisar entre locatários, exportá-lo e configurar sua retenção. Um administrador que pode alterar uma configuração e apagar as únicas evidências apresenta um modelo de responsabilização diferente daquele com registros retidos de forma independente. Pergunte ao fornecedor como funcionam esses controles, mas não alegue imutabilidade ou resistência à adulteração sem evidências atuais.
A retenção deve ser especificada pelos termos reais suportados pelo produto e pelas obrigações do comprador, e não por um período universal inventado. Esclareça quais eventos estão disponíveis na interface, API e arquivo exportado e se essas visualizações têm a mesma cobertura. Revise o tratamento e os identificadores de fuso horário para que os registros possam ser correlacionados sem depender de nomes que podem mudar. Nenhum registro de auditoria foi recuperado para este manuscrito.
Teste mudanças no ciclo de vida e acesso ao serviço
A redução de função, a desativação do usuário e a revogação de credenciais são eventos separados. RFC 7643 descreve o atributo ativo do SCIM, deixando seu significado definitivo para o provedor de serviços. Isso ilustra por que um comprador não pode presumir que uma atualização de provisionamento revoga todas as sessões ou credenciais de integração existentes. Exija uma explicação atualizada da sessão do produto e do comportamento de acesso não interativo.
O plano de aceitação deve incluir um usuário cuja função seja reduzida enquanto existir uma sessão, uma identidade desabilitada, uma integração com escopo limitado e um administrador autorizado. Verifique o resultado de acesso pretendido em cada caso, incluindo exportações e operações diretas de recursos. Estas são verificações propostas para um ambiente isolado autorizado, e não permissão para testar o serviço de produção de um fornecedor ou o locatário de outro cliente. Nenhuma ação desse tipo foi realizada aqui.
Uma planilha de aceitação do comprador
Crie uma planilha com requisito, motivo comercial, reclamação do fornecedor, configuração suportada, identidade do equipamento, inquilino, ação, resultado esperado, evidência real e limitação não resolvida. Mantenha as evidências das ações permitidas separadas das evidências das ações negadas. Inclua a versão do produto, a data do teste e o ambiente para que o resultado permaneça interpretável após o lançamento. Se um recurso for planejado em vez de implementado, registre esse status sem tratá-lo como cobertura atual.
Para logs de auditoria, adicione o evento esperado e a referência do registro observado para cada ação em que o log é necessário. Um teste que nega corretamente o acesso, mas não produz nenhuma evidência de auditoria esperada, tem um resultado diferente daquele que satisfaz ambos os critérios. Registre quem aceita qualquer limitação e se um controle compensatório foi aprovado. Não transforme a pontuação da lista de verificação de compras em uma garantia de segurança futura.
Diagnóstico ficcional: um espectador que pode exportar
Um comprador fictício vê uma demonstração de um fornecedor na qual o visualizador não pode editar as configurações do domínio. O comprador inicialmente marca a função somente leitura como satisfatória. A matriz pretendida, no entanto, também proíbe exportações em massa de dados brutos de clientes. A demonstração nunca testou exportações, solicitações diretas de recursos ou acesso ao relatório de outro inquilino. A restrição observada abrange apenas uma ação.
A resposta proposta é solicitar evidências baseadas em acessórios autorizados nas operações faltantes e revisar os registros de auditoria resultantes. Se o produto não puder separar a visualização da exportação, o comprador deverá decidir se essa limitação é aceitável, em vez de renomear a função e assumir que o risco desapareceu. Este é um exercício de aquisição fictício, não uma descoberta sobre EmailAuth ou qualquer fornecedor nomeado.
Mantenha a conclusão da compra limitada
Uma conclusão útil identifica requisitos atendidos por evidências, requisitos não atendidos, limitações aceitas por um proprietário e testes ainda em aberto. Ele distingue as opções de configuração do comportamento inerente do produto e não promete isolamento perfeito de um conjunto de testes finito. A decisão pode ser informada sem alegar que todas as versões ou configurações futuras serão cobertas.
O catálogo requer uma matriz de acesso e testes negativos para leituras, exportações, gravações e alterações do ciclo de vida entre locatários. Esses testes 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 o método de avaliação, não uma recomendação de compra baseada em evidências executadas, e nenhum compromisso comercial ou concessão de acesso foi feito.