Cuando se escriben historias de usuario se deben de incluir los criterios de aceptación de estas historias de usuario. En estos criterios de aceptación debe de ir una descripción detallada de lo que se espera que hagan las características esperadas en la historia de usuario. Sin embargo; es muy común que en estos criterios de aceptación olvidemos agregar lo relacionado con seguridad y con validaciones (conceptos totalmente diferentes). Aunque no todas las historias de usuario van a tener necesariamente consideraciones de seguridad o validación, se debe considerar el tema cada vez que se están escribiendo para que el desarrollador las tome en cuenta a la hora de implementar la historia. La siguiente es una lista de categorías que se pueden tomar en cuenta a la hora de escribir las historias de usuario.
Criptografía
Es importante definir si alguna característica de las que se va a implementar en la historia de usuario debe de llevar encriptación. En este tema es importante no ponerse a inventar la rueda y utilizar algoritmos probados que ya existen y que cumplen con todas las medidas de seguridad requeridas por la empresa que usará el software. Igual de importante es utilizar librerías de empresas reconocidas para no poner en riesgo el ítem a desarrollador. También es importante definir cuales características deben de estar encriptadas y cuales no, porque como todo en el mundo de la informática tiene su penalidad, y a mayor seguridad menor desempeño – hay que encriptar, transportar y desencriptar para poder hacer que la transacción trabaje correctamente.
Validación de ingreso de datos
Es importante verificar si los datos que ingresan – por pantalla, a través de un servicio, etc. – estén correctos ya que esto atenta no solo contra la estabilidad del sistema sino también contra la seguridad del mismo ( a través de ataques de SQL Injection o en sitios web usando cross site scripting ). Debemos establecer que datos se deben validar en la historia de usuario.
Autenticación y Autorización
La funcionalidad a desarrollar debe de tener de forma explícita si requiere de autenticación y/o autorización; y si requiere autorización cuales grupos funcionales deberían tener acceso a la característica. Esto evita que los desarrolladores desarrollen servicios, componentes, y componentes de UI totalmente abiertos esperando que alguna otra persona los asegure, poniendo en riesgo la seguridad del ítem a desarrollar y por ende, el sistema completo.
No hay comentarios:
Publicar un comentario