Verificações de aceitação para um gateway VPN virtual com autenticação de dois fatores
Comprove o gateway etapa por etapa: inscrição, início de sessão, negação, revogação e restauração, cada uma com um artefato e uma condição de aprovação escrita antes do teste.
Os fornecedores descrevem este equipamento como virtual e capaz de dois fatores, e nenhuma das duas palavras responde às perguntas que decidem a compra. Que imagem de hipervisor é suportada, que clientes se podem inscrever, o que o segundo fator prova realmente e o que acontece quando o fornecedor de identidade falha continuam em aberto. Transforme-as em etapas de aceitação que possa executar num ensaio, e a decisão deixa de depender de quão persuasiva é a ficha técnica. A folha abaixo é uma estrutura para essas provas, não uma classificação de produtos.
O que o fornecedor deve confirmar sobre esta implementação
Comece por fixar a implementação numa página: o hipervisor ou a nuvem, a arquitetura convidada, a imagem suportada e as interfaces que o equipamento espera. Acrescente os utilizadores, com os seus sistemas operativos, se os dispositivos são geridos e como devem funcionar a inscrição e o início de sessão. Depois o acesso privado: aplicações e prefixos, disposição de DNS, caminhos de retorno e se uma saída pública para a internet faz parte da oferta.
As operações pertencem à mesma página: quem mantém o equipamento, de onde vêm as atualizações, para onde vão os registos, como a configuração é protegida e que objetivo de recuperação o negócio realmente acordou. Peça ao fornecedor que confirme exatamente essa combinação, e não que o software corre numa máquina virtual. Mantenha visíveis as dependências externas, como um fornecedor de identidade ou um serviço de licenciamento, porque fazem parte da implementação quer sejam fornecidas com ela ou não. Uma página de implementação sem dependência nomeada é geralmente uma página de implementação com uma dependência desconhecida.
Prove que o segundo fator é um segundo fator
Nomeie o autenticador e o fluxo de verificação, e diga que identidade cada passo estabelece. Dois pedidos de palavra-passe seguidos não são um segundo fator, e uma palavra-passe mais um código de utilização única é uma afirmação diferente da de um autenticador criptográfico ligado ao serviço. Escreva o fluxo que está a comprar, não o rótulo na caixa.
A resistência ao phishing é uma propriedade separada, e a orientação do NIST sobre autenticadores trata-a como tal: um código que um utilizador pode ser enganado a reenviar ainda satisfaz a autenticação multifator mas falha essa condição adicional. Peça a propriedade explicitamente se ela lhe importa. Depois exija uma demonstração com o tipo de cliente que os seus utilizadores realmente executam, que cubra a inscrição, um desafio rejeitado ou expirado, a recuperação após perda do autenticador e a revogação de um utilizador enquanto os outros continuam ligados. Mantenha a verificação de identidade do gateway no âmbito, porque um cliente que confia em qualquer gateway moveu o problema em vez de o resolver.
Escreva a condição de aprovação antes de quebrar alguma coisa
A tabela abaixo é a parte da folha que sobrevive ao contacto com um fornecedor, porque cada linha pede um artefacto em vez de uma garantia. Preencha a condição de aprovação antes do ensaio, e trate uma linha sem provas como uma linha falhada. Cinco etapas cobrem o que um gateway tem de fazer.
| Acceptance stage | Evidence to keep | Pass condition |
|---|---|---|
| Enrolment | Enrolment record with the device type and the identity used | A new device enrols once, and nobody else can enrol it afterwards |
| Sign-in with the second factor | Session record naming both factors and the gateway identity that was checked | The session carries the expected identity and the gateway certificate validated |
| Denial of an unapproved destination | Log line from the control that refused the flow, with the policy name | The flow is refused and the refusal is attributable to one control |
| Revocation of one user | Revocation timestamp and the sessions that survived it | The named user is out and unaffected users keep working |
| Restore from configuration backup | Restored version plus a probe of a revoked identity | The revision matches the backup and revoked identities stay revoked |
A inscrição vem primeiro porque tudo o que se segue depende dela: um dispositivo que não consegue inscrever-se não pode ser testado. O início de sessão é uma etapa separada da inscrição, e a negação é a etapa que mais folhas esquecem, porque um gateway que admite todos não demonstrou que nega alguém. A revogação e a restauração concentram a maior parte do risco operacional, e ambas são baratas de ensaiar numa cópia.
Ensaiem na cópia, não no gateway em produção
Execute as etapas perturbadoras numa cópia da plataforma, seguindo o procedimento de implementação suportado, e guarde cada prova com a sua data e versão de configuração. Uma linha de reinício não se responde com um reinício a partir da consola, e uma linha de restauração não se responde exportando a configuração. Anote que estado regressa sozinho e o que tem de se voltar a ligar, porque é essa diferença que a equipa de operações herda. O ensaio é também a única ocasião de cronometrar uma restauração sem ter de explicar uma falha.
Registe o estado do fornecedor de identidade no momento de cada teste, porque uma linha de falha testada contra um fornecedor saudável prova o contrário do que a folha afirma. Dois revisores no mesmo ensaio apanham coisas diferentes, e o segundo costuma encontrar a linha cuja prova é uma captura de ecrã de um painel. Mantenha essa prova anexada à linha a que pertence, não numa pasta com o nome do projeto.
Meça a carga de trabalho que a sua equipa vai executar
Acorde uma carga semelhante a uma semana normal, e depois meça-a onde pretende implementar: concorrência, mistura de tráfego e a janela de manutenção que a equipa realmente tem. Um valor de débito anunciado descreve uma condição de laboratório e não diz nada sobre os seus utilizadores. Meça a restauração contra o objetivo de recuperação, não contra o plano.
A folha está terminada quando cada etapa tem um artefacto e cada artefacto tem uma data. Um equipamento que alguém mantém, com provas para cada linha, é uma compra diferente da lista mais longa de caixas assinaladas.