Mucho se habla acerca de la Seguridad Informática hoy en día, sobre los intrusos, los estafadores y las tácticas que se recomiendan poner en práctica para por lo menos dificultarles cumplir con su objetivo. Pero este artículo no tratará sobre ciberseguridad, sino sobre uno mismo como el mayor peligro inminente.

¿Sabía usted que una simple gorra puede funcionar como equipo de seguridad? Existen puestos de trabajo en donde la gente está expuesta a diversos obstáculos y un accidente que ocurre con frecuencia (pudiendo ir de lo insignificante a lo grave) es golpearse en la frente, incluso quemársela. No siempre es necesario utilizar un casco (sobre todo si el trabajo es más operativo que técnico, las estaciones de trabajo están prácticamente diseñadas para trabajar con seguridad), una simple gorra puede evitar que alguien acuda a un evento importante con una cicatriz en la frente. La gorra no lo estará protegiendo de ningún compañero sino de su propio descuido.

Cuando se está diseñando un sistema es muy importante tener en cuenta que nuestro subconsciente es el enemigo principal. De poco serviría tener un sistema de autenticación por credenciales si se dejó libre una API que cualquiera puede utilizar y que devuelve información privada de otros usuarios, o que permite realizar acciones para las cuales no cualquiera debería tener el permiso. Algún usuario con un poco de curiosidad podría causar graves problemas.

En ocasiones, cuando todo el trabajo lo hace una misma persona, se puede suponer que entiende cómo está todo relacionado y que no se saboteará a sí mismo. No se podría estar más equivocado o es que acaso no ha oído hablar sobre la Ley de Murphy. Pero se pone peor, en un caso real (no académico) en un mismo proyecto participa más de una persona. Entonces, ¿cómo se le explicaría a alguien más todo lo que debe y no debe de hacer en todo momento? No se puede, no es viable.

Supóngase que hay cuatro personas trabajando en un sitio web, una de ellas se encarga de la base de datos relacional, otra se ocupa de la programación del lado del servidor, otra más de la programación del lado del cliente y la última, del diseño de las interfaces gráficas que se mostrarán al usuario final. Como la base de datos funge como la interpretación de la realidad y de ésta se desprende todo lo demás, su encargado deberá tener la responsabilidad de no solamente crear la estructura y llenarla con datos, sino también de proteger la integridad de la información. Para ello puede optar por hacer procedimientos que serán utilizados por el encargado de la programación del lado del servidor, quien no tendrá acceso a realizar ninguna acción más que las que están estipuladas en éstos. Hasta este punto está protegiendo el sistema de su compañero. Pero, ¿y si los procedimientos están errados? Puede que sí o puede que no, o puede ser que ante el cambio de alguna especificación ya no sean adecuados. Sin duda alguna, llegarán datos con errores, y ésa normalmente es responsabilidad del usuario final, aunque muy probablemente los errores cometidos por él sean fáciles de corregir. No obstante, pueden ocurrir errores garrafales que puedan provocar un caos, incluso la caída de todas las aplicaciones que se sirven de los datos. Supóngase que el primer encargado tiene un procedimiento que borra registros o que un día realizando modificaciones borra por error un producto del cual existen cientos o miles de compras, pedidos, cancelaciones, etcétera; de un momento a otro se caerá el sistema y las llamadas saturarán las líneas telefónicas. “Si se hubiera puesto la gorra no se hubiera pegado en la frente”. El buen uso de restricciones automáticas previamente definidas como claves foráneas, primarias, disparadores, entre otras le hubieran impedido cometer ese gran error. Entre más restrictivo se vuelva el sistema, menos dolores de cabeza para la empresa. Con restricciones bien definidas, el carnaval de errores que pudieran estar cometiendo sus compañeros no provocaría daños catastróficos en su lado, podría conservar la calma e ir a apoyarlos o viceversa.

Ahora se dará un último ejemplo, pero esta vez del lado del cliente. Imagínese que en la base de datos hay registros sobre empleados, de los cuales, uno de sus atributos es la fecha de nacimiento, el cual es un valor independiente de cualquier variable en el sistema. Del lado del cliente se requiere mostrar la edad de los empleados en pantalla, el cual es un dato dependiente de la fecha de nacimiento y que por ello no requiere un espacio en la base de datos, sólo existirá de manera temporal en las memorias RAM. Para lograr esto diseña una clase que representa el modelo de datos de un empleado y entre sus atributos tiene la edad y la fecha de nacimiento; ambos atributos son de acceso público, a la fecha le asigna directamente el valor que obtuvo de la base de datos y la edad la calcula y la asigna al atributo. Crear una instancia de un objeto empleado se puede hacer en diversos escenarios, no solamente en el vaciado de información a una pantalla, el valor de la edad también se puede utilizar para hacer validaciones internas. En algún momento la aplicación se vuelve tan compleja que se vuelve cansado tener que estar revisando si en todos los casos en donde se instancia este tipo de objeto se está calculando la edad, a un compañero suyo se le pudo olvidar y probablemente mostrará al usuario información inconsistente. Quizás esto no parezca un gran problema, pero pueden existir modelos de datos tan complejos que es mejor cuidarse de uno mismo desde el principio. Lo más adecuado en este caso debió haber sido definir los atributos como privados (como es recomendado), definir un método setter para el campo de la fecha de nacimiento que en su interior asegurara la consistencia con el campo de la edad y métodos getter para ambos.

Para concluir, es recomendable considerar siempre restricciones pensando en “qué pasaría si…” para mantener una mejor consistencia en la información, prevenir errores y detectar más rápido errores que surjan cuando haya actualizaciones.