La autenticación multifactor, a menudo denominada MFA, es una segunda verificación además de una contraseña: un código de una aplicación, un SMS o una clave física. La cuestión de si es obligatoria para una empresa de software no puede responderse con un simple sí o no, porque la Directiva NIS2 no prescribe una técnica específica. El artículo 21 obliga a las organizaciones sujetas a obligaciones de diligencia a adoptar medidas apropiadas para la protección del acceso y la autenticación multifactor, y los supervisores examinan dónde es mayor el riesgo.
En la práctica, para una empresa de software hay dos lugares muy diferentes: la cadena de suministro de software con la que usted trabaja, y el software que entrega a los clientes. Ambos requieren una evaluación propia, y esa evaluación no es igualmente estricta en todas partes.
Dos lugares donde la verificación multifactor juega un papel
El primer lugar es interno: el entorno en el que trabajan sus desarrolladores. Código fuente, cadena de desarrollo, consolas en la nube y los sistemas con los que se implementa en producción. El segundo lugar está en el producto en sí: si el software que construye o entrega tiene una pantalla de inicio de sesión, la autenticación multifactor también es un tema allí, tanto para sus propios usuarios como para los usuarios finales de su cliente. Un cuestionario de seguridad de un cliente casi siempre pregunta sobre ambos, a menudo en preguntas separadas que están formuladas de manera diferente a la que usted esperaría.
En el acceso a su cadena de desarrollo
Aquí están las expectativas más sólidas. Quién puede acceder al código fuente, quién puede implementar en producción, y quién tiene derechos administrativos en el entorno en la nube, representa el mayor riesgo si una contraseña simplemente se roba o se reutiliza. Para estas cuentas, la autenticación multifactor se considera una medida básica en casi todos los marcos de seguridad, y también es lo que los supervisores y clientes esperan primero. El control de versiones, la cadena de desarrollo en sí, y en particular cualquier cuenta con derechos para llevar código a producción, deben estar protegidos en la práctica sin excepción por un segundo factor.
Esto también incluye una revisión de quién realmente necesita ese acceso. Un registro que establece quién puede acceder a cada sistema y por qué facilita responder a esta pregunta en un cuestionario con una respuesta concreta en lugar de con una suposición. cómo se explican el control de acceso y la autenticación multifactor por tema proporciona un punto de partida para esto.
En el software que entrega
El segundo aspecto es el software en sí. Si su producto tiene una función de inicio de sesión, la pregunta de si ofrece autenticación multifactor casi siempre aparece en un cuestionario de seguridad, y a veces incluso como requisito contractual. Esta es una evaluación diferente a la de su propia cadena de desarrollo: aquí no se trata de lo que usted mismo utiliza, sino de lo que entrega a su cliente. Un cliente que también está sujeto a obligaciones de diligencia debe, según el artículo 21, evaluar también su cadena de suministro, y la cuestión de si su producto admite autenticación fuerte es parte de ello.
La respuesta no tiene que ser que sea obligatorio en todas partes. A menudo es suficiente demostrar que la opción existe, que se alienta a los usuarios a utilizarla, y que tiene un plan para expandirla donde el riesgo lo justifique.
Donde es menos evidente
No toda cuenta ni todo entorno requiere el mismo nivel de rigor. Un entorno de prueba sin datos reales de clientes, un sistema interno de documentación con solo permisos de lectura, o una herramienta aislada que utiliza ocasionalmente un desarrollador, tienen un peso diferente al de una cuenta con acceso a producción. Las medidas de cuidado requieren medidas que se correspondan con los riesgos, no aplicar la misma capa pesada en todas partes. Los reguladores evalúan esto sobre la base de la proporcionalidad, lo que significa que una opción justificada de no aplicar verificación multifactor en un lugar puede formar parte de un expediente de conformidad de la misma manera que los lugares donde sí se aplica.
La justificación es la palabra clave aquí. Una opción sin explicación puede parecer fácilmente una omisión en un cuestionario, mientras que la misma opción con una breve justificación suele ser exactamente la respuesta que un cliente está buscando.
Lo que esto significa para la conversación con un cliente
Un cliente que envía un cuestionario generalmente no quiere saber si cumple con cada detalle, sino si sabe dónde están sus riesgos y cómo los gestiona de manera consciente. Para la verificación multifactor, esto significa: poder demostrar qué hay en la línea de desarrollo, qué hay en el producto, y por qué el resto está configurado de manera diferente. Quién haya documentado esto por sistema con un estado y un responsable, no necesitará buscar la respuesta de nuevo cuando llegue el próximo cuestionario.
Si y cómo esto se desarrolla exactamente para su propia organización depende de su función en la cadena de suministro y de lo que sus clientes pregunten específicamente; en caso de duda, consulte el texto de la Directiva misma o a un asesor. Si primero desea saber dónde se encuentra, la verificación gratuita en algunas preguntas ofrece una primera indicación, y una explicación de de dónde procede la información muestra cómo se llega a esa indicación.
Si desea leer más ampliamente cómo este tema se relaciona con las otras medidas de cuidado, lo encontrará en la descripción general de temas por situación. El análisis rápido y la base de conocimientos están disponibles de forma gratuita, sin que necesite crear una cuenta.