Arquitectura de software

¿Qué es arquitectura de software? En los inicios de la informática, la programación se consideraba un arte y se desarrollaba como tal, debido a la dificultad que entrañaba para la mayoría de las personas, pero con el tiempo se han ido descubriendo y desarrollando formas y guías generales, con base a las cuales se puedan resolver los problemas. A estas, se les ha denominado Arquitectura de Software, porque, a semejanza de los planos de un edificio o construcción, estas indican la estructura, funcionamiento e interacción entre las partes del software.

Arquitectura de software La Arquitectura del Software es el diseño de más alto nivel de la estructura de un sistema. Una Arquitectura de Software, también denominada Arquitectura lógica, consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco La arquitectura de software define, de manera abstracta, los componentes que llevan a cabo alguna tarea de computación, sus interfaces y la comunicación entre ellos. Toda arquitectura debe ser implementable en una arquitectura física, que consiste simplemente en determinar qué computadora tendrá asignada cada tarea.

Arquitectura de software Una arquitectura de software se selecciona y diseña con base en objetivos (requerimientos) y restricciones. Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los de tipo funcional, también otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e interacción con otros sistemas de información. Las restricciones son aquellas limitaciones derivadas de las tecnologías disponibles para implementar sistemas de información. Unas arquitecturas son más recomendables de implementar con ciertas tecnologías mientras que otras tecnologías no son aptas para determinadas arquitecturas. Por ejemplo, no es viable emplear una arquitectura de software de tres capas para implementar sistemas en tiempo real.

Descomposición modular El diseño modular propone dividir el sistema en partes diferenciadas y definir sus interfaces. sus ventajas: claridad, reducción de costos y reutilización. Los pasos a seguir son: 1. Identificar los módulos. 2. Describir cada módulo. 3. Describir las relaciones entre módulos.

Descomposición modular Una descomposición modular debe poseer ciertas cualidades mínimas para que se pueda considerar suficiente validad. 1. Independencia funcional 2. Acoplamiento 3. Cohesión 4. Comprensibilidad 5. Adaptabilidad

Descomposición modular Independencia funcional Cada módulo debe realizar una función concreta o un conjunto de funciones afines. Es recomendable reducir las relaciones entre módulos al mínimo. Para medir la independencia funcional hay dos criterios: acoplamiento y cohesión.

Descomposición modular Acoplamiento El acoplamiento es una medida de la interconexión entre módulos en la estructura del programa. Se tiende a que el acoplamiento sea lo menor posible, esto es a reducir las interconexiones entre los distintos módulos en que se estructure nuestra aplicación. El grado de acoplamiento mide la interrelación entre dos módulos, según el tipo de conexión y la complejidad de la interfaces: Fuerte Por contenido, cuando desde un módulo se puede cambiar datos locales de otro. Común, se emplea una zona común de datos a la que tienen acceso varios módulos. Moderado De control, la zona común es un dispositivo externo al que están ligados los módulos, esto implica que un cambio en el formato de datos los afecta a todos. Débil De datos, viene dado por los datos que intercambian los módulos. Es el mejor. Sin acoplamiento directo, es el acoplamiento que no existe

Descomposición modular Cohesión Un módulo coherente ejecuta una tarea sencilla en un procedimiento y requiere poca interacción con procedimientos que se ejecutan en otras partes de un programa. Podemos decir que un módulo coherente es aquel que intenta realizar solamente una cosa.

Descomposición modular Comprensibilidad Para facilitar los cambios, el mantenimiento y la reutilización de módulos es necesario que cada uno sea comprensible de forma aislada. Para ello es bueno que posea independencia funcional, pero además es deseable: Identificación, el nombre debe ser adecuado y descriptivo Documentación, debe aclarar todos los detalles de diseño e implementación que no queden de manifiesto en el propio código

Descomposición modular Adaptabilidad La adaptación de un sistema resulta más difícil cuando no hay independencia funcional, es decir, con alto acoplamiento y baja cohesión, y cuando el diseño es poco comprensible. Otros factores para facilitar la adaptabilidad: Previsión, es necesario prever que aspectos del sistema pueden ser susceptibles de cambios en el futuro, y poner estos elementos en módulos independientes, de manera que su modificación afecte al menor número de módulos posibles Accesibilidad, debe resultar sencillo el acceso a los documentos de especificación, diseño, e implementación para obtener un conocimiento suficiente del sistema antes de proceder a su adaptación Consistencia, después de cualquier adaptación se debe mantener la consistencia del sistema, incluidos los documentos afectados.

Patrones de diseño Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces. Un patrón de diseño resulta ser una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.

Patrones de diseño Los patrones de diseño pretenden: Proporcionar catálogos de elementos reusables en el diseño de sistemas software. Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente. Formalizar un vocabulario común entre diseñadores y desarrolladores. Estandarizar el modo en que se realiza el diseño. Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente. No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo problema o similar que soluciona el patrón, siempre teniendo en cuenta que en un caso particular puede no ser aplicable.

Patrones de diseño Tipos de patrones: Patrones creacionales Corresponden a patrones de diseño software que solucionan problemas de creación de instancias. Nos ayudan a encapsular y abstraer dicha creación. Patrones estructurales Son los patrones de diseño software que solucionan problemas de composición (agregación) de clases y objetos. Patrones de comportamiento Se definen como patrones de diseño software que ofrecen soluciones respecto a la interacción y responsabilidades entre clases y objetos, así como los algoritmos que encapsulan.

Patrones de diseño Patrones creacionales Object Pool: se obtienen objetos nuevos a través de la clonación. Utilizado cuando el costo de crear una clase es mayor que el de clonarla. Especialmente con objetos muy complejos. Se especifica un tipo de objeto a crear y se utiliza una interfaz del prototipo para crear un nuevo objeto por clonación. El proceso de clonación se inicia instanciando un tipo de objeto de la clase que queremos clonar. Abstract Factory: permite trabajar con objetos de distintas familias de manera que las familias no se mezclen entre sí y haciendo transparente el tipo de familia concreta que se esté usando. El problema a solucionar por este patrón es el de crear diferentes familias de objetos, como por ejemplo la creación de interfaces gráficas de distintos tipos (ventana, menú, botón, etc.).

Patrones de diseño Patrones creacionales Builder: abstrae el proceso de creación de un objeto complejo, centralizando dicho proceso en un único punto. Factory Method: centraliza en una clase constructora la creación de objetos de un subtipo de un tipo determinado, ocultando al usuario la casuística, es decir, la diversidad de casos particulares que se pueden prever, para elegir el subtipo que crear. Parte del principio de que las subclases determinan la clase a implementar. Prototype: crea nuevos objetos clonándolos de una instancia ya existente. Singleton: garantiza la existencia de una única instancia para una clase y la creación de un mecanismo de acceso global a dicha instancia. Restringe la instanciación de una clase o valor de un tipo a un solo objeto. A continuación se muestra un ejemplo de este patrón:

Patrones de diseño Patrones creacionales Model View Controller (MVC), es un patrón de arquitectura de software que separa los datos y la lógica de negocio de una aplicación de la interfaz de usuario y el módulo encargado de gestionar los eventos y las comunicaciones. Este patrón plantea la separación del problema en tres capas: la capa model, que representa la realidad; la capa controller , que conoce los métodos y atributos del modelo, recibe y realiza lo que el usuario quiere hacer; y la capa vista, que muestra un aspecto del modelo y es utilizada por la capa anterior para interaccionar con el usuario.

Patrones de diseño MVC

Patrones de diseño Patrones estructurales Adapter o Wrapper: adapta una interfaz para que pueda ser utilizada por una clase que de otro modo no podría utilizarla. Bridge (Puente): Desacopla una abstracción de su implementación. Composite (Objeto compuesto): Permite tratar objetos compuestos como si de uno simple se tratase. Decorator (Decorador): Añade funcionalidad a una clase dinámicamente. Facade (Fachada): Provee de una interfaz unificada simple para acceder a una interfaz o grupo de interfaces de un subsistema. Flyweight (Peso ligero): Reduce la redundancia cuando gran cantidad de objetos poseen idéntica información. Proxy: Mantiene un representante de un objeto.

Patrones de diseño Patrones de comportamiento Chain of Responsibility (Cadena de responsabilidad): Permite establecer la línea que deben llevar los mensajes para que los objetos realicen la tarea indicada. Command (Orden): Encapsula una operación en un objeto, permitiendo ejecutar dicha operación sin necesidad de conocer el contenido de la misma. Interpreter (Intérprete): Dado un lenguaje, define una gramática para dicho lenguaje, así como las herramientas necesarias para interpretarlo. Iterator (Iterador): Permite realizar recorridos sobre objetos compuestos independientemente de la implementación de estos. Mediator (Mediador): Define un objeto que coordine la comunicación entre objetos de distintas clases, pero que funcionan como un conjunto.

Patrones de diseño Patrones de comportamiento Memento (Recuerdo): Permite volver a estados anteriores del sistema. Observer (Observador): Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambie de estado se notifique y actualicen automáticamente todos los objetos que dependen de él. State (Estado): Permite que un objeto modifique su comportamiento cada vez que cambie su estado interno. Strategy (Estrategia): Permite disponer de varios métodos para resolver un problema y elegir cuál utilizar en tiempo de ejecución. Template Method (Método plantilla): Define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos, esto permite que las subclases redefinan ciertos pasos de un algoritmo sin cambiar su estructura. Visitor (Visitante): Permite definir nuevas operaciones sobre una jerarquía de clases sin modificar las clases sobre las que opera.

Patrones de diseño

Arquitecturas distribuidas Un sistema distribuido es un sistema en el que el procesamiento de información se distribuye sobre varias computadoras en vez de estar confinado en una única máquina. Se identifican las siguientes ventajas del uso de una aproximación distribuida para el desarrollo de sistemas: Compartición de recursos. Un sistema distribuido permite compartir recursos hardware y software – como discos, impresoras, archivos y compiladores – que se asocian con computadoras de una red.

Arquitecturas distribuidas Apertura. Los sistemas distribuidos son normalmente sistemas abiertos, lo que significa que se diseñan sobre protocolos estándar que permiten combinar equipamiento y software de diferentes vendedores. Concurrencia. En un sistema distribuido, varios procesos pueden operar al mismo tiempo sobre diferentes computadoras de la red. Estos procesos pueden (aunque no necesariamente) comunicarse con otros durante su funcionamiento normal.

Arquitecturas distribuidas Escalabilidad. Al menos en principio, los sistemas distribuidos son escalables en tanto que la capacidad del sistema puede incrementarse añadiendo nuevos recursos para cubrir nuevas demandas sobre el sistema. Tolerancia a defectos. La disponibilidad de varias computadoras y el potencial para reproducir información significa que los sistemas distribuidos pueden ser tolerantes a algunos fallos de funcionamiento del hardware y del software.

Arquitecturas distribuidas Para sistemas organizacionales a gran escala, estas ventajas significan que los sistemas distribuidos han reemplazado ampliamente a los sistemas heredados centralizados que fueron desarrollados en los años 80 y 90. Sin embargo, comparados con sistemas que se ejecutan sobre un único procesador o un clúster de procesadores, los sistemas distribuidos tienen varias desventajas: Complejidad. Los sistemas distribuidos son más complejos que los sistemas centralizados. Esto hace más difícil comprender sus propiedades emergentes y probar estos sistemas. Por ejemplo, en vez de que el rendimiento del sistema dependa de la velocidad de ejecución de un procesador, depende del ancho de banda y de la velocidad de los procesadores de la red.

Arquitecturas distribuidas Seguridad. Puede accederse al sistema desde varias computadoras diferentes, y el tráfico en la red puede estar sujeto a escuchas indeseadas. Esto hace más difícil el asegurar que la integridad de los datos en el sistema se mantenga y que los servicios del sistema no se degraden por ataques de denegación de servicio. Manejabilidad. Las computadoras en un sistema pueden ser de diferentes tipos y pueden ejecutar versiones diferentes de sistemas operativos. Los defectos en una máquina pueden propagarse a otras máquinas con consecuencias inesperadas. Impredecibilidad. Como todos los usuarios de la WWW saben, los sistemas distribuidos tienen una respuesta impredecible. La respuesta depende de la carga total en el sistema, de su organización y de la carga de la red.

Arquitecturas distribuidas Los componentes en un sistema distribuido pueden implementarse en diferentes lenguajes de programación y pueden ejecutarse en tipos de procesadores completamente diferentes. Los modelos de datos, la representación de la información y los protocolos de comunicación pueden ser todos diferentes. Un sistema distribuido, por lo tanto, requiere software que pueda gestionar estas partes distintas, y asegurar que dichas partes se puedan comunicar e intercambiar datos.

Arquitecturas distribuidas Los sistemas distribuidos se desarrollan normalmente utilizando una aproximación orientada a objetos. Estos sistemas están formados por partes independientes pobremente integradas, cada una de las cuales pueden interaccionar directamente con los usuario o con otras partes del sistema. Algunas partes del sistema pueden tener que responder a eventos independientes. Los objetos software reflejan estas características; por lo tanto, son abstracciones naturales para los componentes de sistemas distribuidos.

Arquitectura multiprocesador Un sistema multiproceso o multitarea es aquel que permite ejecutar varios procesos de forma concurrente, la razón es porque actualmente la mayoría de las CPU’s sólo pueden ejecutar un proceso cada vez. La única forma de que se ejecuten de forma simultánea varios procesos es tener varias CPU’s (ya sea en una máquina o en varias, en un sistema distribuido.

Arquitectura multiprocesador El multiproceso no es algo difícil de entender: más procesadores significa más potencia computacional. Un conjunto de tareas puede ser completado más rápidamente si hay varias unidades de proceso ejecutándolas en paralelo. Esa es la teoría, pero otra historia es la práctica, como hacer funcionar el multiproceso, lo que requiere unos profundos conocimientos tanto del hardware como del software. Es necesario conocer ampliamente como están interconectados dichos procesadores, y la forma en que el código que se ejecuta en los mismos ha sido escrito para escribir aplicaciones y software que aproveche al máximo sus prestaciones.

Arquitectura multiprocesador La ventaja de un sistema multiproceso reside en la operación llamada cambio de contexto. Esta operación consiste en quitar a un proceso de la CPU, ejecutar otro proceso y volver a colocar el primero sin que se entere de nada.

Arquitectura multiprocesador Ventajas: Es económica. El uso de componentes comúnmente disponibles, en grandes cantidades, permite ofrecer mayor rendimiento, a un precio menor que el de máquinas con procesadores especialmente diseñados. Adicionalmente, las computadoras paralelas son inherentemente escalables, permitiendo actualizarlas para adecuarlas a una necesidad creciente. Las arquitecturas “tradicionales” se actualizan haciendo los procesadores existentes obsoletos por la introducción de nueva tecnología a un costo posiblemente elevado.

Arquitectura multiprocesador Desventajas: En ocasiones se menciona también la limitante física; existen factores que limitan la velocidad máxima de un procesador, independientemente del factor económico. Barreras físicas infranqueables, tales como la velocidad de la luz, efectos cuánticos al reducir el tamaño de los elementos de los procesadores, y problemas causados por fenómenos eléctricos a pequeñas escalas, restringen la capacidad máxima de un sistema uniprocesador, dejando la opción obvia de colocar muchos procesadores para realizar cálculos cooperativamente. Es necesario conocer ampliamente como están interconectados dichos procesadores, y la forma en que el código que se ejecuta en los mismos ha sido escrito para escribir aplicaciones y software que aproveche al máximo sus prestaciones.

Arquitectura cliente - servidor Esta arquitectura consiste básicamente en un cliente que realiza peticiones a otro programa (el servidor) que le da respuesta. Aunque esta idea se puede aplicar a programas que se ejecutan sobre una sola computadora es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras. La interacción cliente-servidor es el soporte de la mayor parte de la comunicación por redes. Ayuda a comprender las bases sobre las que están construidos los algoritmos distribuidos.

Arquitectura cliente - servidor Cliente: Programa ejecutable que participa activamente en el establecimiento de las conexiones. Envía una petición al servidor y se queda esperando por una respuesta. Su tiempo de vida es finito una vez que son servidas sus solicitudes, termina el trabajo. Servidor: Es un programa que ofrece un servicio que se puede obtener en una red. Acepta la petición desde la red, realiza el servicio y devuelve el resultado al solicitante. Al ser posible implantarlo como aplicaciones de programas, puede ejecutarse en cualquier sistema donde exista TCP/IP y junto con otros programas de aplicación. El servidor comienza su ejecución antes de comenzar la interacción con el cliente. Su tiempo de vida o de interacción es “interminable”.

Arquitectura cliente - servidor Los servidores pueden ejecutar tareas sencillas (caso del servidor hora día que devuelve una respuesta) o complejas (caso del servidor ftp en el cual se deben realizar operaciones antes de devolver una respuesta). Los servidores sencillos procesan una petición a la vez (son secuenciales o interactivos), por lo que no revisan si ha llegado otra petición antes de enviar la respuesta de la anterior. Los más complejos trabajan con peticiones concurrentes aún cuando una sola petición lleve mucho tiempo para ser servida (caso del servidor ftp que debe copiar un archivo en otra máquina). Son complejos pues tienen altos requerimientos de protección y autorización. Pueden leer archivos del sistema, mantenerse en línea y acceder a datos protegidos y a archivos de usuarios.

Arquitectura cliente - servidor Características: Combinación de un cliente que interactúa con el usuario, y un servidor que interactúa con los recursos a compartir. El proceso del cliente proporciona la interfaz entre el usuario y el resto del sistema. El proceso del servidor actúa como un motor de software que maneja recursos compartidos tales como bases de datos, impresoras, etc. Las tareas del cliente y del servidor tienen diferentes requerimientos en cuanto a recursos de cómputo como velocidad del procesador, memoria, velocidad y capacidades del disco, etc.

Arquitectura cliente - servidor Características: Se establece una relación entre procesos distintos, los cuales pueden ser ejecutados en la misma máquina o en máquinas diferentes distribuidas a lo largo de la red. Existe una clara distinción de funciones basadas en el concepto de “servicio”, que se establece entre clientes y servidores. La relación establecida puede ser de muchos a uno, en la que un servidor puede dar servicio a muchos clientes, regulando su acceso a los recursos compartidos. Los clientes corresponden a procesos activos en cuanto a que son estos los que hacen peticiones de servicios. Estos últimos tienen un carácter pasivo, ya que esperan peticiones de los clientes.

Arquitectura cliente - servidor Características: No existe otra relación entre clientes y servidores que no sea la que se establece a través del intercambio de mensajes entre ambos. El mensaje es el mecanismo para la petición y entrega de solicitudes de servicios. El ambiente es heterogéneo. La plataforma de hardware y el sistema operativo del cliente y del servidor no son siempre los mismos. Precisamente una de las principales ventajas de esta arquitectura es la posibilidad de conectar clientes y servidores independientemente de sus plataformas. El concepto de escalabilidad tanto horizontal como vertical es aplicable a cualquier sistema Cliente-Servidor. La escalabilidad horizontal permite agregar más estaciones de trabajo activas sin afectar significativamente el rendimiento. La escalabilidad vertical permite mejorar las características del servidor o agregar múltiples servidores.

Arquitectura cliente - servidor Ventajas: Existencia de plataformas de hardware cada vez más baratas. Esta constituye a su vez una de las más palpables ventajas de este esquema, la posibilidad de utilizar máquinas mucho más baratas que las requeridas por una solución centralizada, basada en sistemas grandes (mainframes). Además, se pueden utilizar componentes, tanto de hardware como de software, de varios fabricantes, lo cual contribuye considerablemente a la reducción de costos y favorece la flexibilidad en la implantación y actualización de soluciones.

Arquitectura cliente - servidor Ventajas: Facilita la integración entre sistemas diferentes y comparte información, permitiendo por ejemplo que las máquinas ya existentes puedan ser utilizadas pero utilizando interfaces más amigables el usuario. De esta manera, se puede integrar PCs con sistemas medianos y grandes, sin necesidad de que todos tengan que utilizar el mismo sistema operativo.

Arquitectura cliente - servidor Ventajas: Al favorecer el uso de interfaces gráficas interactivas, los sistemas construidos bajo este esquema tienen una mayor y más intuitiva con el usuario. En el uso de interfaces gráficas para el usuario, presenta la ventaja, con respecto a uno centralizado, de que no siempre es necesario transmitir información gráfica por la red pues esta puede residir en el cliente, lo cual permite aprovechar mejor el ancho de banda de la red.

Arquitectura cliente - servidor Ventajas: La estructura inherentemente modular facilita además la integración de nuevas tecnologías y el crecimiento de la infraestructura computacional, favoreciendo así la escalabilidad de las soluciones. Contribuye además a proporcionar a los diferentes departamentos de una organización, soluciones locales, pero permitiendo la integración de la información.

Arquitectura cliente - servidor Desventajas: El mantenimiento de los sistemas es más difícil pues implica la interacción de diferentes partes de hardware y de software, distribuidas por distintos proveedores, lo cual dificulta el diagnóstico de fallas. Cuenta con muy escasas herramientas para la administración y ajuste del desempeño de los sistemas. Es importante que los clientes y los servidores utilicen el mismo mecanismo (por ejemplo sockets o RPC), lo cual implica que se deben tener mecanismos generales que existan en diferentes plataformas.

Arquitectura cliente - servidor Desventajas: Hay que tener estrategias para el manejo de errores y para mantener la consistencia de los datos. El desempeño (performance), problemas de este estilo pueden presentarse por congestión en la red, dificultad de tráfico de datos, etc.

Seguridad en ingeniería de software La seguridad de información, se refiere a la seguridad de información comúnmente como la protección de sistemas de información contra el acceso desautorizado o la modificación de información, si está en una fase de almacenamiento, procesamiento o tránsito. También la protege contra la negación de servicios a usuarios desautorizados y la provisión de servicio a usuarios desautorizados, incluyendo las medidas necesarias para detectar, documentar, y contrariar tales amenazas.

Seguridad en ingeniería de software Muchas preguntas con respecto a la seguridad, son relacionadas al ciclo vital de software. En particular, la seguridad del código y el proceso de software; deben de ser considerados durante la fase del diseño y desarrollo. Además, la seguridad debe de ser preservada durante la operación y el mantenimiento para asegurar la integridad de una parte de software.

Seguridad de software El concepto de la seguridad en los sistemas de software es un área de investigación que ha pasado a ser vital dentro de la Ingeniería de Software. Con el crecimiento de Internet, y otras aplicaciones sobre redes, como el comercio electrónico, correo electrónico, etc., la posibilidad de ataques se ha incrementado notablemente, como también lo han hecho las consecuencias negativas de estos ataques. En la actualidad prácticamente todo sistema debe incorporar cuestiones de seguridad para defenderse de ataques maliciosos. El desarrollador ya no sólo debe concentrarse únicamente en los usuarios y sus requerimientos, sino también en los posibles atacantes.

Seguridad de software Siempre que se utilice un sistema informático, sin importar cuál sea la razón, es importante que se tenga como prioridad la instalación de un software de seguridad, teniendo en cuenta la cantidad de riesgos que corremos con un sistema informático sin protección. Tipos de software de seguridad: Programa antivirus Cortafuegos Filtro antispam Software para filtrar contenidos Software contra publicidad no deseada

Seguridad en el ciclo de desarrollo de software La mayor parte de las organizaciones desarrolla o contrata el desarrollo de aplicaciones propias para su gestión de negocio. Como todo software, estas aplicaciones pueden contener fallas de seguridad y a diferencia del software comercial, no se dispone de actualizaciones o parches liberados en forma periódica por el fabricante. El tratamiento de las vulnerabilidades en aplicaciones propias corre por parte de la organización que las desarrolla.

Seguridad en el ciclo de desarrollo de software Lamentablemente es una práctica habitual en muchas organizaciones la “puesta en producción” de sistemas sin la participación del sector de Seguridad de la Información. Muchas otras veces, el sector de Seguridad se entera demasiado tarde, y no tiene suficiente margen de acción para el análisis de seguridad de la aplicación desarrollada. Por lo general, en el mejor de los casos, se coordina un testeo de seguridad una vez que la aplicación ya está desarrollada. Aquí muchas veces se encuentran errores que requieren el rediseño de parte de la aplicación, lo cual implica un costo adicional en tiempo y esfuerzo.

Seguridad en el ciclo de desarrollo de software Seguridad en el análisis En esta etapa, se deben identificar aquellos requerimientos funcionales que tendrán impacto en los aspectos de seguridad de la aplicación. Algunos de ellos son: tipo de información que se transmitirá o procesará (ejemplo: Información pública o confidencial, datos personales, datos financieros, contraseñas, datos de pago electrónico, etc.) y requerimientos de registros de auditoría (ejemplo: Qué debe registrar la aplicación en sus Logs).

Seguridad en el ciclo de desarrollo de software Seguridad en el diseño Antes de comenzar a escribir líneas de código, hay numerosos aspectos de seguridad que deben ser tenidos en cuenta durante el diseño de la aplicación. Diseño de autorización. Definir los roles, permisos y privilegios de la aplicación Diseño de autenticación. LDAP, Active Directory, otros servicios.

Seguridad en el ciclo de desarrollo de software Mecanismos que tendrá la aplicación para evitar ataques de diccionario o de fuerza bruta. Bloqueo de cuentas, implementación de “captchas”, etc. Diseño de los mensajes de error y advertencia. Evitar que brinden demasiada información. Mecanismos de protección de datos. Encriptación, hashes o truncamiento de la información.

Seguridad en el ciclo de desarrollo de software Seguridad en el desarrollo Una vez concluido el diseño, le toca a los desarrolladores el turno de codificar los distintos componentes de la aplicación. Es en este punto en donde suelen incorporarse, por error u omisión, distintos tipos de vulnerabilidades. Estas vulnerabilidades podríamos dividirlas en dos grandes grupos a saber: vulnerabilidades clásicas y vulnerabilidades funcionales. Las primeras son bien conocidas y categorizadas.

Seguridad en el ciclo de desarrollo de software Seguridad en el desarrollo Ejemplo de estas vulnerabilidades son las presentes en el “OWASP Top 10” (Vulnerabilidades de inyección, Cross Site Scripting, errores en manejo de sesiones, etc.) como así también otras vulnerabilidades no ligadas directamente con las aplicaciones WEB, como desbordamiento de buffer, denegación de servicio, etc. Los ‘Frameworks’ de desarrollo de aplicaciones son una buena ayuda en este punto, ya que ofician de intermediario entre el programador y el código, y permiten prevenir la mayoría de las vulnerabilidades conocidas. Ejemplos de estos frameworks son .NET, Struts, Ruby on Rails y Zope.

Seguridad en el ciclo de desarrollo de software Seguridad en el desarrollo Vulnerabilidades funcionales son aquellas ligadas específicamente a la funcionalidad de negocio que posee la aplicación, por lo que no están previamente categorizadas. Algunos ejemplos ilustrativos de este tipo de vulnerabilidad son los siguientes: una aplicación de banca electrónica que permite realizar transferencias con valores negativos, un sistema de subastas que permite ver los valores de otros oferentes, un sistema de venta de entradas para espectáculos que no impone límites adecuados a la cantidad de reservas que un usuario puede hacer.

Seguridad en el ciclo de desarrollo de software Seguridad en el desarrollo Vulnerabilidades funcionales son aquellas ligadas específicamente a la funcionalidad de negocio que posee la aplicación, por lo que no están previamente categorizadas. Algunos ejemplos ilustrativos de este tipo de vulnerabilidad son los siguientes: una aplicación de banca electrónica que permite realizar transferencias con valores negativos, un sistema de subastas que permite ver los valores de otros oferentes, un sistema de venta de entradas para espectáculos que no impone límites adecuados a la cantidad de reservas que un usuario puede hacer.

Seguridad en el ciclo de desarrollo de software Seguridad en el desarrollo En la etapa de codificación, una de las reglas de oro es verificar todos los valores de entrada y de salida. Esto es, asumir siempre que el valor pudo haber sido manipulado o ingresado maliciosamente antes de ser procesado. NUNCA CONFIAR EN LOS DATOS DE ENTRADA

Confiabilidad del software La confiabilidad de software significa que un programa particular debe de seguir funcionando en la presencia de errores. Los errores pueden ser relacionados al diseño, a la implementación, a la programación, o el uso de errores. Así como los sistemas llegan a ser cada vez más complejos, aumenta la probabilidad de errores.

Confiabilidad del software Aunque casi todos los software tengan errores, la mayoría de los errores nunca serán revelados debajo de circunstancias normales. Un atacante busca esta debilidad para atacar un sistema. La calidad es un atributo percibido por los usuarios o clientes de cualquier producto o servicio. En el caso de productos basados en software, la percepción de la calidad está en función de las fallas que el cliente percibe del mismo durante su operación.

Confiabilidad del software La confiabilidad es un atributo que mide el grado en que un producto opera sin fallas bajo condiciones establecidas por un periodo de tiempo determinado. La confiabilidad es un atributo cuantitativo que ha sido ampliamente analizado, estudiado y usado en otras industrias para caracterizar la calidad de los productos o servicios.

Confiabilidad del software Se dice que un Software es confiable si realiza lo que el usuario desea, cuando así lo requiera. No es confiable si así no lo hiciera. A nuestros fines un Software no es Confiable cuando falla. Las fallas se deben a errores en el Software. Si corregimos estos errores sin introducir nuevos, mejoramos la Confiabilidad del Software.

Ingeniería de seguridad La Ingeniería de la seguridad es una rama de la ingeniería, que usa todo tipo de ciencias para desarrollar los procesos y diseños en cuanto a las características de seguridad, controles y sistemas de seguridad. La principal motivación de esta ingeniería ha de ser el dar soporte de tal manera que impidan comportamientos malintencionados.

Ingeniería de seguridad El campo de esta ingeniería puede ser muy amplio, podría desarrollarse en muchas técnicas: Equipos: Como el diseño de cerraduras, cámaras, sensores,... Procesos: políticas de control, procedimientos de acceso,... Informático: control de passwords, criptografía,...

Ingeniería de seguridad Tradicionalmente el tema de la seguridad en sistemas computarizados se ha asociado a la criptografía y sus técnicas. La inmensa complejidad que caracteriza a los sistemas modernos hace que esta aproximación sea insuficiente. Un sistema puede tener mecanismos criptográficos que sean considerados completamente seguros pero puede adolecer de debilidades que hagan que sea innecesario atacar al sistema criptográfico.

Ingeniería de seguridad Tradicionalmente el tema de la seguridad en sistemas computarizados se ha asociado a la criptografía y sus técnicas. La inmensa complejidad que caracteriza a los sistemas modernos hace que esta aproximación sea insuficiente. Un sistema puede tener mecanismos criptográficos que sean considerados completamente seguros pero puede adolecer de debilidades que hagan que sea innecesario atacar al sistema criptográfico.

Ingeniería de seguridad Ejemplos: Sistemas que fallan debido a problemas en el código, como en la mayoría de los ataques conocidos como de “buffer overflow”, en los cuales el no considerar aspectos de excepción asociados a los sistemas pueden representar que un atacante suficientemente hábil pueda asumir funciones del administrador. Si en un determinado sistema alguien asume las funciones del administrador puede tener muy fácil acceso a claves y sistemas criptográficos haciendo inútil la fortaleza del sistema criptográfico que lo protege.

Ingeniería de seguridad Ejemplos: Algunos ataques aprovechan fallas de diseño en los sistema. Si una determinada aplicación ejecuta sin evaluar un determinado comando, los atacantes del sistema pueden conseguir información vital sin necesidad de romper las claves criptográficas que lo protegen. La existencia de sistemas de comunicación móvil, basados en transmisión inalámbrica facilita actividades de fisgoneo en la señal.

Ingeniería de seguridad Algunas veces lo que se conoce como ataques de ingeniería social pueden resultar muy efectivos a la hora de atacar sistema supuestamente seguros. La poca comprensión que algunos implementadores de sistemas tienen sobre los mecanismos de seguridad implícitos también ocasiona que ciertos sistemas sean más vulnerables.