A verificação em múltiplos fatores, frequentemente chamada de MFA, é uma segunda verificação além de uma senha: um código de um aplicativo, um SMS ou uma chave física. A questão de se isso é obrigatório para uma empresa de software não pode ser respondida com um simples sim ou não, pois a Diretiva NIS2 não prescreve uma técnica específica. O artigo 21 obriga as organizações que se enquadram na obrigação de diligência a adotar medidas adequadas para proteção de acesso e autenticação em múltiplos fatores, e as autoridades regulatórias avaliam onde o risco é maior.
Para uma empresa de software, na prática, isso ocorre em dois locais muito diferentes: a linha de desenvolvimento que você usa, e o software que você entrega aos clientes. Ambos exigem uma análise separada, e essa análise não é igualmente rigorosa em todos os lugares.
Dois locais onde a verificação em múltiplos fatores desempenha um papel
O primeiro local é interno: o ambiente em que seus desenvolvedores trabalham. Código-fonte, a linha de desenvolvimento, consoles em nuvem e os sistemas com os quais você implanta na produção. O segundo local está no próprio produto: se o software que você constrói ou entrega possui uma tela de login, a verificação em múltiplos fatores também é um tema relevante, tanto para seus próprios usuários quanto para os usuários finais do seu cliente. Uma lista de verificação de segurança de um cliente quase sempre pergunta sobre ambos, frequentemente em perguntas separadas que são formuladas de forma ligeiramente diferente do que você esperaria.
No acesso à sua linha de desenvolvimento
Aqui existe a expectativa mais forte. Quem pode acessar o código-fonte, quem pode implantar na produção e quem tem direitos administrativos no ambiente em nuvem representa o maior risco se uma senha for apenas roubada ou reutilizada. Para essas contas, a verificação em múltiplos fatores é considerada uma medida básica em praticamente todo estrutura de segurança, e também é o que as autoridades regulatórias e os clientes esperam primeiro. Controle de versão, a própria linha de desenvolvimento, e particularmente qualquer conta com direitos para levar código para produção, devem, na prática, sem exceção estar atrás de uma segunda etapa.
Isso também inclui uma análise sobre quem realmente ainda precisa desse acesso. Um registro em que por sistema está definido quem pode acessar e por quê, facilita responder essa pergunta em uma lista de verificação com uma resposta concreta em vez de com uma suposição. como controle de acesso e verificação em múltiplos fatores são explicados por tópico fornece um ponto de partida para isso.
No software que você entrega
O segundo aspecto é o próprio software. Se seu produto possui uma função de login, a pergunta sobre se você oferece verificação em múltiplos fatores quase sempre retorna em uma lista de verificação de segurança, e às vezes até como requisito contratual. Essa é uma análise diferente da sua própria linha de desenvolvimento: aqui não se trata do que você mesmo usa, mas do que você oferece ao seu cliente. Um cliente que se enquadra na obrigação de diligência também deve, conforme o artigo 21, avaliar sua cadeia de suprimentos, e a questão de se seu produto suporta autenticação forte faz parte disso.
A resposta não precisa ser que seja obrigatório em todos os lugares. Muitas vezes, é suficiente demonstrar que a funcionalidade existe, que os usuários são incentivados a usá-la, e que você tem um plano para expandi-la onde o risco o justifique.
Onde é menos óbvio
Nem toda conta ou ambiente requer o mesmo nível de rigor. Um ambiente de teste sem dados reais de clientes, um sistema interno de documentação com apenas permissões de leitura, ou uma ferramenta isolada usada ocasionalmente por um desenvolvedor pesam diferentemente de uma conta com acesso à produção. A obrigação de diligência requer medidas proporcionais aos riscos, não a aplicação da mesma camada pesada em toda parte. Os supervisores avaliam isso com base no princípio da proporcionalidade, o que significa que uma escolha fundamentada de não aplicar autenticação multifator em determinado local pode fazer parte de um dossiê tanto quanto os locais onde ela está implementada.
A fundamentação é aqui a palavra mais importante. Uma escolha sem explicação parece rapidamente ser uma omissão em um questionário, enquanto a mesma escolha com uma breve justificativa é frequentemente exatamente a resposta que um contratante procura.
O que isto significa para a conversa com um contratante
Um contratante que envia um questionário geralmente não quer saber se você cumpre cada detalhe, mas se você compreende onde estão seus riscos e como lida conscientemente com eles. Para autenticação multifator, isto significa: poder mostrar o que existe na linha de desenvolvimento, o que existe no produto, e por que o resto está organizado de forma diferente. Quem tiver documentado isto por sistema com um estado e um responsável não precisa procurar a resposta novamente quando o próximo questionário chegar.
Se e como isto se concretiza exatamente para sua organização depende de seu papel na cadeia de suprimentos e do que seus clientes especificamente perguntam; em caso de dúvida, consulte o texto da diretiva em si ou um consultor. Se deseja primeiro saber onde você está, a verificação gratuita em algumas perguntas oferece uma primeira indicação, e uma explicação sobre a origem da informação mostra como essa indicação é desenvolvida.
Se deseja ler mais amplamente como esse assunto se relaciona com as outras medidas da obrigação de diligência, você encontrará em a visão geral dos tópicos por situação. A verificação rápida e a base de conhecimento são livremente acessíveis, sem a necessidade de criar uma conta.