Andres
4 años (10 Pts)

¿Tu sistema esta seguro?

Cuánto vale tu información para ti?, es la pregunta que te tienes que hacer cuando le vas a implementar seguridad a tus sistemas, quedate conmigo un rato y platicaremos sobre algunos tips de seguridad y cuando es importante implementarla.

Como decía una vez un profesor mio, si la seguridad te va salir mas caro de lo que vale tu información, pues entonces no la protejas, pero aun que no lo crean hay información que realmente vale una fortuna y los intrusos harán lo que sea para conseguirla, y es ahí cuando si vale la pena poner candados por todos lados, sin embargo debo mencionar, que ningún sistema hecho por el hombre es, ni será 100% seguro, nunca!, eso no existe, siempre habrá forma de acceder a ella, entonces que hacer?, nuestra responsabilidad como desarrolladores es ponerle todas las barreras posibles al intruso y hacer uso de mecanismos de confirmación de identidad.

Bitácora de Errores.

Es indispensable para cualquier sistema tener una bitácora de errores, la cual puede ser una tabla en nuestra base de datos, donde nosotros debemos almacenar: IdUsuario, fechaHora, operación que intento realizar antes de entrar a una excepción, linea de código, ruta del archivo donde esta esa linea de código, versión del sistema (si, tu sistema debe estar liberado con un numero de versión productiva), de esa forma sabremos si el error es por que no tiene el sistema actualizado, para nosotros sera mucho mas fácil hacer el monitoreo de los errores de nuestro sistema con esta bitácora, por que?, pues por que muchas veces nuestros usuario no recuerda que fue lo que hicieron para que el sistema les falle.

Conexión.

Nuestras conexiones deber ser intimamente paranoicas y exageradas, es preferible mil veces ser exagerados que lamentarnos y eso sale hasta mas caro. Nuestra conexión al servidor lo mejor es que sea a través de una variable de entorno en el servidor, y crear una Capa únicamente para acceder a esa variable de entorno, los accesos nunca deben estar en nuestro código, nunca!

Accesos a base de datos.

El tema de los accesos debemos tener en nuestro equipo a un experto que se encargue de implementar todos los mecanismos para acceder a los datos, sin embargo muchas veces no tenemos a alguien especialmente para este perfil, entonces si te toco hacer todo como comúnmente, recomiendo que todas tus consultas sean a través de procedimientos almacenados. Y crear en tu base de datos roles de usuarios, los cuales pueden ser configurados para tener acceso a los procedimientos almacenados que tu le indiques, y por ente vas a tener una conexión distinta por cada usuario, la cual tienes que agregar como variable de entorno en el servidor. De esta forma cada usuario solo tendrá acceso a ciertos procedimientos, ya ni siquiera a ninguna tabla, solo a los procedimientos. La asignación de conexiones por usuario ya es la lógica que tu vas a implementar aparte, para saber que conexión le darás a cada usuario.

Políticas de password.

Aunque no lo crean 12345 sigue siendo la contraseña mas utilizada por los mismos administradores de base de datos, es el colmo, de los usuarios se entiende, pero un dba?, es imperdonable, pero bueno el otro colmo es que los que no usan 12345, tienen su password en un postip pegado en su computadora a la vista de todos, ya no me sorprende. Aquí te dejo una políticas obligatorias:

1.- mínimo 6 caracteres

2.- máximo 15 caracteres

3.- al menos una mayúscula

4.- al menos una minúscula.

5.- al menos 1 numero.

6.- al menos 1 caracter especial.

Sesion de usuario.

A cuantos nos ha pasado que olvidamos abierta nuestra cuenta de Facebook en el ciber, y cuando entramos a nuestra cuenta notamos que ya nos trolearon ?, yo creo que a más de 1, bueno pues lo mismo pasa con los sistemas, solo que como es información de la empresa y no mía, pues al usuario no le importa, sin embargo a nosotros si, por que si la información que genere el usuario nosotros la damos como integra, pero nada lo garantiza, una medida de seguridad para mitigar un problema así, es programar nuestros sistemas para que se cierren de forma automática despues de al menos 10 minutos de inactividad, es decir, 10 minutos que el usuario no lo ha usado, debe ser un fastidio para el usuario tener que autenticarse a cada rato, pero ni modos, es por su seguridad.

Web service

Al publicar nuestros web service nosotros tenemos que hacerlo a través de un puerto diferente al 80, o 8080, por qué? Pues por que esos puertos son los mas atacados en la web, adicional debemos hacer de forma obligatoria que los datos viajen a través de un canal seguro HTTPS y debe estar validado con un certificado SSL , para evitar que un tercero mire nuestra información.

Trazabilidad

Debemos tener siempre otra bitácora donde almacenemos las acciones que hace nuestro usuario, no es mas que una tabla, con los siguientes campos: idUsuario, fechaHora, operación (alta, baja o modificación), cuando sea modificación, debemos almacenar como estaba antes, y como quedo despues, debemos también almacenar el id de los que agrego y el nombre de lo que elimino ( si es que tiene el permiso de hacerlo )

Login

Para la autenticación de nuestro usuario, sea por un web service, debe estar por un canal seguro, para que ningún tercero mire la contraseña de nuestro usuario, la cual deberá ser encriptada por un algoritmo de una sola vía, es decir que no haya forma de ser descifrada, ejemplo: sha512 o sha256. En nuestra base de datos también la debemos tener encriptada, ni siquiera el dba debe saber ninguna sola contraseña, esto hará que el usuario sea el único responsable de los registros generados con su usuario. Al momento d e autenticarse, nuestro sistema debemos deshabilitar la opción de copiar y pegar.

Conclusión

Usa los mecanismos de acuerdo al valor de tu información.