Problemática

Una de las grandes problemáticas al momento de acceder a los datos, es que la implementación y formato de la información puede variar según la fuente de los datos. Implementar la lógica de acceso a datos en la capa de lógica de negocio puedes ser un gran problema, pues tendríamos que lidiar con la lógica de negocio en sí, más la implementación para acceder a los datos, adicional, si tenemos múltiples fuentes de datos o estas pueden variar, tendríamos que implementar las diferentes lógicas para acceder las diferentes fuentes de datos, como podrían ser: bases de datos relacionales, No SQL, XML, archivos planos, Webservices, etc).

Solución

Dado lo anterior, el patrón DAO propone separar por completo la lógica de negocio de la lógica para acceder a los datos, de esta forma, el DAO proporcionará los métodos necesarios para insertar, actualizar, borrar y consultar la información; por otra parte, la capa de negocio solo se preocupa por lógica de negocio y utiliza el DAO para interactuar con la fuente de datos.

Los compones que conforman el patrón son:

• BusinessObject: representa un objeto con la lógica de negocio.
• DataAccessObject: representa una capa de acceso a datos que oculta la fuente y los detalles técnicos para recuperar los datos.
• TransferObject: este es un objeto plano que implementa el patrón Data Transfer Object (DTO), el cual sirve para transmitir la información entre el DAO y el Business Service.
• DataSource: representa de forma abstracta la fuente de datos, la cual puede ser una base de datos, Webservices, LDAP, archivos de texto, etc.

El siguiente diagrama muestra mejor la forma en que funciona el patrón, pues muestra de forma secuencial la forma en que se ejecutaría el patrón.

El diagrama se interpreta de la siguiente manera:

1. El BusinessObject creo u obtiene una referencia al DataAccessObject.
2. El BusinessObject solicita información al DataAccessObject
   • El DataAccessObject solicita la información al DataSource
   • El DataAccessObject crea una instancia del TransferObject con los datos recuperados del DataSource
   • El DataAccessObject response con el TransferObject creado en los pasos anteriores.
3. El BusinessObject actualiza algún valor del TransferObject
   • Más actualizaciones
4. El BusinessObject solicita el guardado de los datos actualizados al DataAccessObject.
   • El DataAccessObject guarda los datos en el DataSource.

Como hemos podido ver, el BusinessService no se preocupa de donde vengan los datos ni cómo deben de ser guardados en el DataSource, el solo se preocupa por conocer el TransferObject. Un error común al implementar este patrón es no utilizar TransferObject y en su lugar, regresar los objetos que regresan las mismas API’s de las fuentes de datos, ya que esto obliga al BusinessService tener una dependencia con estas librerías, además, si la fuente de datos cambia, también cambiarán estas clases, lo que provocaría una afectación directa al BusinessService.

Hace unos días escribir sobre el patrón Data Transfer Object (DTO) por si quieres profundizar en el tema.

DAO y el patrón Abstract Factory

Hasta este punto solo hemos analizado como trabajaríamos si solo tuviéramos una fuente de datos, sin embargo, existe ocasiones donde requerimos obtener datos de más de una fuente, y es allí donde entra el patrón de diseño Abstract Factory el cual explico perfectamente en mi libro “Introducción a los patrones de diseño”.

Mediante el patrón Abstract Factory podemos definir una serie de familias de clases que permitan conectarnos a las diferentes fuentes de datos. Para esto, examinaremos un sistema de autenticación de usuarios, el cual puede leer los usuarios en una base de datos o sobre un XML, adicional, el sistema generara registros de login que podrán ser utilizados para auditorias.

Lo primero sería implementar las clases para acceder de las dos fuentes:

En la imagen anterior podemos apreciar dos familias de clases, con las cuales podemos obtener los Usuarios y los registros de auditoria, sin embargo, estas clases por separado no ayudan mucho, pues no implementan una misma interface que permita la variación entre ellas, por lo que el siguiente paso es crear estas interfaces:

En este punto, los DAO ya implementan una interfaz común, lo que permite intercambiar la implementación sin afectar al Business Object. Sin embargo, ahora solo falta resolver la forma en que el Business Service obtendrá la familiar de interfaces, es por ello que deberemos crear un Factory para cada familia de interfaces:

En esta nueva configuración, podemos ver que tenemos un Factory para cada familia, y los dos factorys implementan una interfaz en común, adicional, tenemos la interface IDAOFactory necesaria para que el factory de cada familia implementen una interface en común.

Analicemos como quedaría la secuencia de ejecución

1. El BusinessObject solicita la creación de un DAOFactory para SQL
   • El DAOFactory crea una instancia de la clase SQLDAOFactory y la retorna
2. El BusinessObject solicita al SQLDAOFactory la creación del SQLUserDAO para interactuar con los usuarios.
   • El SQLDAOFactory crea una nueva instancia del SQLUserDAO
   • El SQLDAOFactory retorna la instancia creada del SQLUserDAO
3. El BusinessObject solicita el listado de todos los usuarios registrados al SQLUserDAO
   • El SQLUserDAO recupera los usuarios del SQLDataSource
   • El SQLUserDAO crea un TransferObject con los datos recuperados del paso anterior.
   • El SQLUserDAO retorna el TransferObject creado en el paso anterior.

Adicional a los pasos que hemos listado aquí, podríamos solicitar al SQLDAOFactory la creación del SQLAuditDAO o incluso, solicitar al DAOFactory la creación del XMLFactory para interactuar con la fuente de datos en XML.

Conclusiones

El patrón DAO es sin lugar a duda, unos de los más utilizados en la actualidad, ya que es fácil de implementar y proporciona claros beneficios, incluso, si solo tenemos una fuente de datos y esta no cambia, pues permite separar por completo la lógica de acceso a datos en una capa separada y así solo nos preocupamos por la lógica de negocio sin preocuparnos de donde viene los datos o los detalles técnicos para consultarlos o actualizarlos.

The post Data Access Object (DAO) Pattern appeared first on Oscar Blancarte - Software Architecture.

Cada día las aplicaciones tiene mayor necesidad de intercambiar mensajes con el fin de integrar aplicaciones o de comunicar algo a otras aplicaciones, este tipo de intercambio de mensajes ha crecido a un mas con la llegada de la arquitectura orientada a Servicios(SOA), ya que ha creado un ambiente propicio para que las aplicaciones intercambien mensajes de un punto a otro.

Sea cual sea la el motivo por el cual un mensaje es enviado de un punto a otro es indispensable asegurarnos que los mensajes sean enviados en un canal seguro y que el mensaje enviado sea el mismo que se reciba del otro lado sin ninguna alteración, también existen escenario en los que los mensajes contienen información altamente confidencial como datos de nuestros clientes o cuentas bancarias por lo que somos responsables de asegurarnos que la información continué siendo confidencial.

La pregunta aquí es, que mecanismos podemos implementar para que nuestros mensajes sean enviados en un canal seguro, el cual impida que nuestro mensaje sea alterado o descifrado por terceras personas.

Antes de contestar estas preguntas es importante entender que es la Confidencialidad, Integridad y Autenticidad en mensajes por lo que empezaremos con definir estos términos:

• Confidencialidad: Es la capacidad de un mensaje para mantener oculto su contenido de tal forma que si una tercera persona ve el mensaje no pueda interpretar su contenido.
• Integridad: Se refiere a que los elementos mensajes, datos, documentos, y otros formas de contenido no han sido modificados en tránsito o en reposo.
• Autenticidad: Se refiere a garantizar que el mensaje ha sido enviado por quien dice ser.

Puede que estos tres términos no nos queden muy claros por lo que a continuación hablaremos mas a detalle de cada tema.

Confidencialidad:

La confidencialidad de la información es un tema que tenemos que tener muy presente ya que cada vez que enviamos información por la red estamos exponiéndola a que otras personas no autorizadas puedan interceptarlas y hacer con ellas mucho daño.

En la imagen anterior podemos ver que un mensaje es enviado de un punto A a un punto B, sin embargo el mensaje no se encuentra cifrado ni se envía por un canal seguro, por lo que podrías ser fácilmente interceptado por una tercera persona.

Esta tercera persona podría tener solo curiosidad de ver que hay en el mensaje o podría estar intencionalmente interceptando estos mensajes para hacernos algún daño, en este punto ya hemos perdido la confidencialidad de los datos ya que esta persona ha podido ver la información que hemos enviado.

Una de las forma de evitar esto es enviar el mensaje por un canal seguro como https o SSL lo cual hace que nuestro mensaje vaya cifrado desde que sale de nuestro servidor hasta que llega al servidor destino, de esta forma es mucho mas difícil que nuestro intruso pueda recuperar el mensaje original y revelar la información que este contiene.

Como podemos apreciar en la imagen, nuestro intruso recibe una copia del mensaje cifrado por lo que sera prácticamente imposible que descifre su contenido.

Otra alternativa es cifrar el contenido del mensaje y enviar el mensaje por un canal seguro como en el punto anterior, esto nos garantiza tener una seguridad mucho mas fuerte ya que si el intruso logra por alguna razón descifrar el mensaje del canal seguro se presentara con el problema de que el mensaje descifrado esta nuevamente cifrado pero esta vez a nivel del contenido.

Existen distintos mecanismos de cifrado que nos permitirá enviar mensaje cifrados de un punto a otro y tener la capacidad de descifrar nuevamente el mensaje una vez que llegue a su destino, uno de los algoritmos de cifrado mas utilizados es RSA.

Autenticidad:

La autenticidad es algo muy serio cuando hablamos de mensajes ya que de esta forma certificamos que la persona que nos envió el mensaje no es un impostor que se hace pasar por otra entidad. Este tipo de escenarios es muy común cuando nuestro impostor trata de hacer algún daño a nuestros sistemas enviando mensajes para realizar ciertas tareas en nombre de otra entidad.

Para prevenir este tipo de ataque es importante que las dos partes sea identificadas antes de que un mensaje sea enviado, para esto se utilizan un intercambio de llaves, son creadas dos llaves, una publica y una privada, la privada nos servirá para cifrar los mensajes, la publica nos servirá para descifrar el mensaje  y validar que el mensaje enviado aya sido enviado por la persona que tiene la llave privada.

De esta forma, cuando un mensaje sea enviado de un punto A a un punto B, el punto A enviara el mensaje cifrado con la llave secreta y lo enviara al punto B, el punto B descifrara el mensaje enviado por A y validara que el mensaje fue enviado por A.

En la imagen podemos apreciar el proceso por el cual un punto A y un Punto B hacen un intercambio de llaves, los pasos son los siguientes:

1. El servidor A crea un par de llaves, una publica y una privada, la privada se la quedara el y sera el único que sepa de la existencia de esta llave, la publica por otra parte es enviada al punto B con el fin de que este sea capas de descifrar los mensajes que vienen de A y a si asegurarse de que A fue el que realmente envió el mensaje.
2. El servidor A envía un mensaje B y lo cifra con la llave privada que creo en el primer paso.
3. B recibe el mensaje y utiliza la llave publica para descifrar el mensaje.
4. Mediante el proceso de descifrado el servidor B puedo estar seguro de que A fue quien realmente envió el mensaje.

Integridad:

La integridad por otra parte tiene como objetivo identificar que un mensaje no ha sido manipulado por una tercera persona con el fin de realizar alguna acción en nuestro nombre.

Existe el escenario en que el intruso logra descifrar el mensaje no solo con el fin de conocer su contenido, si no que a demás esta interesado en hacer algún daño haciéndose pasar por otra nosotros y enviar el mensaje que ha capturado pero haciéndole algunas modificaciones adicionales con el fin de provocar mas daño.

En la imagen vemos como nuestro impostor no solo intercepto nuestro mensaje si no que a demás creo un mensaje nuevo basado en el mensaje capturado para enviarlo al destinatario haciéndose pasar por el remitente original. Este nuevo mensaje llegara al destinatario y este pensara que fue enviado por nosotros, esto llevara a que el mensaje sea procesado por el destinatario realizando todos los cambios que este demande.

Para evitar este tipo de problemas es necesario incrustar un sello electrónico dentro del mensaje, este sello es creado combinando la totalidad del mensaje o una parte significativa en una cadena la cual deberá ser pasado por un algoritmo de digestión como MD5, SHA-1, SHA-2 con el fin de crear una cadena mucho mas reducida, esta cadena deberá ser cifrada mediante un certificado de sello digital.

En la imagen podemos ver un ejemplo de un mensaje en XML el cual tiene datos de los clientes, debajo tenemos la cadena original generada a partir del la información del mensaje, notemos que no utilizamos todo el mensaje si no solo sus datos, y al final tenemos la cadena original tras pasar por el proceso de digestión MD5, en este punto solo nos quedara hacer el cifrado de la cadena mediante nuestro certificado de sello digital para tener un verdadero sello digital que garantice la integridad del mensaje.

Finalmente nuestro mensaje quedaría de la siguiente manera:

Cuando el destinatario tome el mensaje, validara que la cadena fue generada con la misma información que contiene el documento. Si un impostor altera el contenido del mensaje no tendrá las llaves para crear el sello electrónico valido, por lo que el destinatario sabrá de inmediato que el mensaje ha sido alterado y su integridad ha sido violada.

En la imagen podemos apreciar como el mensaje original llega al punto B y este de inmediato valida que el sello digital corresponde con la información enviada, por otra parte el intruso crea un nuevo mensaje alterando el contenido del mensaje original, sin embargo, el nuevo mensaje seguirá teniendo el sello original ya que el intruso no tendrá los certificados para crear un nuevo sello basado en la información que altero, El server B detectará esta irregularidad y de inmediato rechazará el mensaje.

Conclusión.

Como ves, existen muchos riesgos cuando de mandar mensaje se trata, por lo que es importante determinar que nivel de seguridad debemos implementar al enviar nuestros mensajes, es por eso que es importante conocer los riesgos y saber las estrategias a tomar para prevenir este tipo de situaciones.

También es importante destacar que estas técnicas son perfectamente combinables para crear un envió mucho mas seguro, por lo que podríamos tener mensajes que contengan sello digital, se envíen cifrados y sobre un canal seguro. esto desde luego logra que nuestro mensaje sea Confidencial, Integro y sea Autentico.

Si te gusto este post no dudes en recomendarlo ya que esto me ayudara a seguir creando mas y mejor material.

The post Seguridad – Confidencialidad, Integridad y Autenticidad en mensajes appeared first on Oscar Blancarte - Software Architecture.