1.
Sistemas de Información Distribuidos Ing. Aldo Zanabria Gálvez UNAP Puno. 2010 9no Semestre – Ingeniería de Sistemas 17/03/11 UNAP - Ing. Aldo Zanabria

2.
17/03/11 UNAP - Ing. Aldo Zanabria Arquitectura Cliente/Servidor

3.
Justificación Cliente/Servidor 17/03/11 UNAP - Ing. Aldo Zanabria

4.
Nuevas Tareas del Dpto. de Sistemas de Información <ul><li>Soporte a la gestión empresarial. Apoyo a los objetivos. </li></ul><ul><li>Selección de Estándares: </li></ul><ul><ul><li>Compatibiliza. </li></ul></ul><ul><ul><li>Facilita al usuario. </li></ul></ul><ul><li>Infraestructura C/S: </li></ul><ul><ul><li>Plataforma operativa. </li></ul></ul><ul><ul><li>Entorno de desarrollo. </li></ul></ul><ul><ul><li>Gestión del SID. </li></ul></ul><ul><ul><li>Arquitectura de la aplicación: </li></ul></ul><ul><ul><ul><li>Portabilidad. </li></ul></ul></ul><ul><ul><ul><li>Interoperatividad. </li></ul></ul></ul><ul><ul><ul><li>Distribuida. </li></ul></ul></ul><ul><li>Desarrollo corporativo (no departamental). </li></ul><ul><li>Integración de aplicaciones propias con estándar. </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

5.
Implicaciones del modelo Cliente/Servidor 17/03/11 UNAP - Ing. Aldo Zanabria

6.
¿Cuándo implantar C/S? <ul><li>Cambios estructurales y organizativos. </li></ul><ul><li>Cambios en organigramas. </li></ul><ul><li>Respuesta dinámica de mercado. </li></ul><ul><li>Cambio en procesos de negocio. </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

7.
¿Qué ayuda a la implantación? <ul><li>La demanda de sistemas fáciles. </li></ul><ul><li>Precio/rendimiento de estaciones y servidores. </li></ul><ul><li>Creciente acceso a la información para decisiones: Separación datos-programas. Programas flexibles. </li></ul><ul><li>Nuevas tecnologías de alta productividad. </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

8.
Cliente/Servidor <ul><li>Definición : Sistema distribuido entre múltiples procesadores donde hay clientes que solicitan servicios y servidores que los proporcionan. </li></ul><ul><li>Separa los servicios situando cada uno en su plataforma más adecuada. </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

9.
Objetivos de C/S <ul><li>Localización transparente. </li></ul><ul><li>Recursos compartidos. </li></ul><ul><li>Escalabilidad </li></ul><ul><ul><li>Horizontal: > nº estaciones. </li></ul></ul><ul><ul><li>Vertical: migración a otras plataformas. </li></ul></ul><ul><li>Interoperatividad entre distintos Hw. y Sw. </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

10.
Evolución <ul><li>1ª ÉPOCA: </li></ul><ul><ul><li>LAN. </li></ul></ul><ul><ul><li>LAN con MAINFRAMES. </li></ul></ul><ul><ul><li>Comunicaciones homogéneas (LU, SNA, APPC). </li></ul></ul><ul><li>2ª ÉPOCA: </li></ul><ul><ul><li>Herramientas de desarrollo C/S. </li></ul></ul><ul><ul><li>Proveedores DBMS con C/S. </li></ul></ul><ul><ul><li>Downsizing: migración a PCs. </li></ul></ul><ul><ul><li>S.O. De red con servidores de servicios. </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

11.
Evolución (II) <ul><li>3ª ÉPOCA: ACTUAL. </li></ul><ul><ul><li>PWS: Estaciones de trabajo programables gráficamente. </li></ul></ul><ul><ul><li>GUI: Interfaz gráfico de usuario. Alta resolución. </li></ul></ul><ul><ul><li>Nuevas tecnologías: Ratón, lápiz óptico, scanner, multimedia. </li></ul></ul><ul><ul><li>Tecnología de componentes: DDE y OLE. </li></ul></ul><ul><ul><li>Conectividad de BDs: ODBC, JDBC </li></ul></ul><ul><ul><li>Objetos Distribuidos: CORBA, COM, COM+, DCOM </li></ul></ul><ul><ul><li>Internet: HTML, CGI, Applet, ActiveX, JAVA, JAVASCRIPT </li></ul></ul><ul><ul><li>Arquitecturas C/S de 2 y 3 niveles. </li></ul></ul><ul><ul><li>Middleware. </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

12.
Tecnología de componentes: DDE y OLE <ul><li>DDE : (Dynamic Data Exchange) ( Microsoft ). </li></ul><ul><ul><li>Enlaces de datos dinámicos. </li></ul></ul><ul><ul><li>Información automáticamente actualizada entre aplicaciones. </li></ul></ul><ul><li>OLE : (Object Linking and Embeding) ( Microsoft ). </li></ul><ul><ul><li>Objetos enlazados y embebidos. </li></ul></ul><ul><ul><li>Enlazado: Guardando una referencia. </li></ul></ul><ul><ul><li>Embebido: Insertando un documento. </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

13.
Conectividad de BDs <ul><li>ODBC : (Open DataBase Conectivity) ( Microsoft ). </li></ul><ul><ul><li>Conectividad abierta entre BDs. </li></ul></ul><ul><ul><li>Interfaz de conexión entre BDs (especialmente Microsoft) </li></ul></ul><ul><li>JDBC : (Java DataBase Conectivity) ( Java ). </li></ul><ul><ul><li>Conectividad abierta entre BDs versión Java. </li></ul></ul><ul><ul><li>Abierto. </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

14.
Objetos Distribuidos <ul><li>CORBA ( Common Object Request Broker Architecture) ( Object Management Group ): Estándar de programación distribuida basada en objetos. </li></ul><ul><li>COM ( Microsoft ): Interface estándar para objetos (no importa cómo están programados). </li></ul><ul><li>COM+ ( Microsoft ): Extensión de COM en el que se añade un modelo para la programación de objetos. </li></ul><ul><li>DCOM ( Microsoft ): Extensión de COM que permiten crear objetos clientes y servidores utilizando COM aunque creando transparencia sobre la localización física del objeto (es decir que puede encontrarse en otra máquina). La gestión de la comunicación está embebida. </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

15.
INTERNET <ul><li>HTML (HyperText Markup Language ) : Lenguaje basado en el estándar SGML de etiquetado para la creación de páginas web en el servidor visibles desde un cliente remoto con su propio visor. </li></ul><ul><li>CGI (Common Gateway Interface): Interface para el tratamiento de ejecutables en el servidor (remoto) a petición de clientes. Rápido y muy modular. </li></ul><ul><li>ActiveX ( Microsoft ) : Objetos visuales de control (desde botones hasta mini-aplicaciones) embebidos en un documento (o página web) que se descargan y se ejecutan en el visor del cliente. </li></ul><ul><li>JAVA ( Sun Microsystems ) : Lenguaje de programación específico para C/S en internet. Lento, con aplicaciones mayores. </li></ul><ul><li>APPLET : Objetos visuales embebidos en una página web (versión abierta de ActiveX). </li></ul><ul><li>JAVABEANS ( Sun Microsystems ) : Especificación para objetos en Java. </li></ul><ul><li>JAVASCRIPT ( Netscape ) : Lenguaje de utilidades para HTML. </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

16.
Evolución (III) <ul><li>EL FUTURO. </li></ul><ul><ul><li>Facilidad de uso de las aplicaciones. </li></ul></ul><ul><ul><li>Accesos a datos distribuidos en cualquier lugar del mundo (y del espacio). </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

17.
MIDDLEWARE <ul><li>Conecta procesos para constituir aplicación. </li></ul><ul><li>Conjunto de funciones + servicios. </li></ul><ul><li>Actúa en el bajo nivel del SID: </li></ul><ul><ul><li>Comunicación. </li></ul></ul><ul><ul><li>Directorios. </li></ul></ul><ul><ul><li>Integridad. </li></ul></ul><ul><li>Define la plataforma de transparencia de localización. </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

18.
Características C/S. <ul><li>Flexibilidad: </li></ul><ul><ul><li>Middleware. </li></ul></ul><ul><ul><li>Separación de funciones: </li></ul></ul><ul><ul><ul><li>Lógica de presentación. </li></ul></ul></ul><ul><ul><ul><li>Lógica de negocio. </li></ul></ul></ul><ul><ul><ul><li>Lógica de datos. </li></ul></ul></ul><ul><ul><li>Encapsulación de servicios. </li></ul></ul><ul><ul><li>Portabilidad - reubicación. </li></ul></ul><ul><ul><li>Operación sincrono - asíncrono. </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

19.
Características C/S (II). <ul><li>Entorno de aplicaciones incremental. </li></ul><ul><ul><li>Añadir un nuevo servidor. </li></ul></ul><ul><ul><li>Añadir un nuevo cliente. </li></ul></ul><ul><ul><li>Modificar un cliente para usar un nuevo servidor. </li></ul></ul><ul><li>Integración: por la GUI. </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

20.
Modelos C/S <ul><li>Presentación distribuida </li></ul><ul><ul><li>Proporciona un API que separa la programación de ventanas del resto. </li></ul></ul><ul><ul><li>Ejemplo: X-Windows System en UNIX o Windows95 y NT. </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria Presentación Negocio Datos C S

21.
Modelos C/S (II) <ul><li>Función distribuida </li></ul><ul><ul><li>Máxima flexibilidad. </li></ul></ul><ul><ul><li>Lógicas de negocio separadas. </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria Presentación Negocio Datos Negocio C S

22.
Modelos C/S (III) <ul><li>Datos distribuidos </li></ul><ul><ul><li>Ficheros distribuidos. </li></ul></ul><ul><ul><li>Bases de datos distribuidas. </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria Presentación Negocio Datos C S

23.
Aplicaciones de 2 y 3 niveles <ul><li>2 niveles: </li></ul><ul><ul><li>Generalmente usa los modelos de función distribuida o datos distribuidos. </li></ul></ul><ul><ul><li>Muy productivo. </li></ul></ul><ul><ul><li>Distribución no flexible. </li></ul></ul><ul><ul><li>Dependiente del suministrador. </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

24.
Aplicaciones de 2 y 3 niveles (II) <ul><li>3 niveles: </li></ul><ul><ul><li>Modelo presentación-negocio-datos </li></ul></ul><ul><ul><li>Distribución flexible. </li></ul></ul><ul><ul><li>Sistema abierto. No dependiente. </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria C C C Negocio

25.
Sistemas abiertos <ul><li>Definición según IEEE: </li></ul><ul><li>“ Un conjunto completo y consistente de estándares internacionales de tecnología de información y de estándares funcionales, que especifica interfaces, servicios y formatos de soporte para conseguir la interoperatividad y portabilidad de aplicaciones, datos y personas”. </li></ul><ul><li>Definición según ISO: </li></ul><ul><li>“ Todo el conjunto de interfaces, servicios y formatos de soporte, además de otros aspectos de usuarios, para la interoperativilidad o la portabilidad de aplicaciones, datos o personas, según se especifica en los estándares y perfiles de tecnología informática” </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

26.
Sistemas Abiertos: Características. <ul><li>Elección libre de plataforma gracias a la portabilidad e interoperatividad. </li></ul><ul><li>Protección de la inversión empresarial. </li></ul><ul><li>Libertad de elección del modelo de distribución: presentación, función o datos distribuidos. </li></ul><ul><li>Explotación de aplicaciones estándar. </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

27.
Estándares <ul><li>Definición: “Conjunto de reglas, definiciones y propiedades mutuamente aceptadas que permite la cooperación de objetos heterogéneos y su utilización” </li></ul><ul><li>Clasificación: </li></ul><ul><ul><li>Por su lugar de publicación: </li></ul></ul><ul><ul><ul><li>Internacional </li></ul></ul></ul><ul><ul><ul><li>Regional (CEE). </li></ul></ul></ul><ul><ul><ul><li>Nacional. </li></ul></ul></ul><ul><ul><li>Por autor: </li></ul></ul><ul><ul><ul><li>De Iure: por comité </li></ul></ul></ul><ul><ul><ul><li>De facto: por fabricante. </li></ul></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

28.
Sistemas abiertos vs propietarios <ul><li>Tiempo de implantación mayor en abiertos: </li></ul><ul><ul><li>Estándar  10 años. </li></ul></ul><ul><ul><li>Alianzas y consorcios (no oficial): medio plazo. </li></ul></ul><ul><ul><li>Tecnologías propietarias portables: corto plazo. </li></ul></ul><ul><ul><li>Tecnologías propietarias: Rápidas. No abiertas. </li></ul></ul><ul><li>Diferenciador de producto: </li></ul><ul><ul><li>Estándar industrial + algo propio. </li></ul></ul><ul><ul><li>Ejemplo: un DBMS con SQL estándar + 4GL propio. </li></ul></ul><ul><li>Arquitecturas de proveedores importantes. </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

29.
Sistemas Abiertos: Factores de éxito. <ul><li>Independencia del suministrador. </li></ul><ul><li>Elección de herramientas: </li></ul><ul><ul><li>Interoperativas: Estándares. </li></ul></ul><ul><ul><li>Portables: Estándar o propietario. </li></ul></ul><ul><li>Arquitectura de la aplicación: </li></ul><ul><ul><li>Buen diseño C/S. </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

30.
Plataformas operativas: Gestores de recursos <ul><li>Definición: ”Programas software que acceden a recursos (dispositivos, ficheros, bases de datos, programas, objetos, etc.) y proporcionan un API”. </li></ul><ul><li>Tipos: </li></ul><ul><ul><li>Local: servicio en s.o. local. </li></ul></ul><ul><ul><li>Remoto: con C/S. </li></ul></ul><ul><ul><li>Distribuido: en varios lugares. </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

31.
Plataformas operativas: Middleware <ul><li>Función de intermediario entre clientes y servidores. </li></ul><ul><li>Otros servicios: </li></ul><ul><ul><li>Directorio de recursos: info. sobre ellos. </li></ul></ul><ul><ul><li>Nominación de recursos. </li></ul></ul><ul><ul><li>Comunicaciones: </li></ul></ul><ul><ul><ul><li>Conversacional (SINC) </li></ul></ul></ul><ul><ul><ul><li>RPC: (SINC) </li></ul></ul></ul><ul><ul><ul><li>Cola de mensajes: (ASINC) </li></ul></ul></ul><ul><ul><li>Seguridad: Login único. </li></ul></ul><ul><ul><li>Gestión de transacciones: única para todos los recursos. </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

32.
Selección de sw C/S <ul><li>Sistema operativo. </li></ul><ul><li>Múltiples modelos de distribución C/S. </li></ul><ul><li>Nuevas tecnologías (POO). </li></ul><ul><li>Apertura. </li></ul><ul><li>Integración con sw estándar. </li></ul><ul><li>Operación C/S (síncrona y asíncrona). </li></ul><ul><li>Herramientas de desarrollo potentes. </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

33.
Ejercicios: 17/03/11 UNAP - Ing. Aldo Zanabria

34.
Ejercicio 1 <ul><li>1) Una empresa localizada en una determinada ciudad A dispone de un sistema con un ordenador multiprocesador de 2 CPUs, con 16 Mbytes de RAM, 2 discos de 1 Gb yte cada uno, 2 terminales locales y una impresora láser en un edificio. Además esta empresa dispone de una delegación situada en una ciudad B a 300 km. de la anterior donde se conecta vía módem un terminal a 9600 bps con una impresora local a éste. En el ordenador central se ejecutan 3 procesos distintos: uno para gestión de los datos de la empresa central, otro para gestionar los de la delegación y un tercer proceso traspasa información entre la base de datos de la central y la de la delegación. Discutir razonadamente: </li></ul><ul><li>a) ¿Podríamos estar ante un sistema distribuido? </li></ul><ul><li>b) ¿Es razonable esta forma de trabajar? ¿Por qué? </li></ul><ul><li>c) ¿Es mejorable? ¿Cómo? </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

35.
Ejercicio 2 <ul><li>2) Supongamos la misma empresa del ejercicio 1 donde ahora tenemos un ordenador en la central y otro ordenador en l a delegación conectados entre sí por un módem de 14400 bps. Cada lugar tiene su propia base de datos y sus propios procesos, y un proceso situado en la central se encarga del traspaso de datos entre las dos empresas. Este proceso lo pone en marcha un opera dor cuando necesita mover los datos de sitio. ¿Es este sistema distribuido? ¿Por qué? </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

36.
CONSIDERACIONES: Aspectos a considerar, tendencias, Desarrollo web, nuevos tipos de dispositivos. 17/03/11 UNAP - Ing. Aldo Zanabria

37.
Aspectos a tener en cuenta en el proceso de ingeniería <ul><li>Protocolos de comunicaciones: </li></ul><ul><ul><li>Son más importantes que la propia arquitectura distribuida o centralizada. Un buen protocolo permite que se pueda pasar, sin un coste adicional de rediseño o codificación, de una arquitectura centralizada a una distribuida, y viceversa: </li></ul></ul><ul><ul><ul><li>Pipes </li></ul></ul></ul><ul><ul><ul><li>RPC </li></ul></ul></ul><ul><ul><ul><li>SQL Remoto </li></ul></ul></ul><ul><ul><ul><li>HTTP </li></ul></ul></ul><ul><ul><ul><li>X11 </li></ul></ul></ul><ul><ul><ul><li>Otros </li></ul></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

38.
Aspectos a tener en cuenta <ul><li>Middleware. Es la herramienta o conjunto de herramientas que nos permitiran gestionar y coordinar los mecanismos de comunicación. </li></ul><ul><ul><li>Independiza el servicio y su implementación, del S.O. y protocolos de comunicaciones </li></ul></ul><ul><ul><li>Permite la convivencia de distintos servicios en una misma máquina </li></ul></ul><ul><ul><li>Modelo tradicional: Monitor de teleproceso </li></ul></ul><ul><ul><ul><li>CICS, Tuxedo, Encina </li></ul></ul></ul><ul><ul><li>Modelo OO: CORBA </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

39.
Aspectos a tener en cuenta <ul><li>Fase de análisis: </li></ul><ul><ul><li>Prácticamente no hay diferencias respecto a un S.I. tradicional </li></ul></ul><ul><ul><li>Se debe definir la política de empresa: fat client o fat server. </li></ul></ul><ul><ul><li>Se debe definir el coste en comunicaciones que puede asumir la organización. </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

40.
Aspectos a tener en cuenta <ul><li>Fase de diseño </li></ul><ul><ul><li>El diseño de entidades, en raras ocasiones se verán éstas afectadas </li></ul></ul><ul><ul><li>Aparecerán nuevos conjuntos de datos en los DFDs. No se trata de nuevas entidades, sino de información que debe viajar entre nodos </li></ul></ul><ul><ul><li>Respecto al diseño de tablas, se debe especificar su implementación: </li></ul></ul><ul><ul><ul><li>Desde qué nodos debe ser accesible </li></ul></ul></ul><ul><ul><ul><li>Qué nivel de acceso se precisa desde cada uno de ellos </li></ul></ul></ul><ul><ul><ul><li>Cómo implementarlo </li></ul></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

41.
Aspectos a tener en cuenta <ul><li>Implementación BB.DD. Distribuidas </li></ul><ul><ul><li>No hay entornos puramente distribuidos. Debe analizarse, tabla a tabla, qué distribuir, qué centralizar y cómo hacerlo: </li></ul></ul><ul><ul><li>Tabla única </li></ul></ul><ul><ul><li>Tablas con réplica simétrica on-line </li></ul></ul><ul><ul><li>Tablas con réplica simétrica off-line ** </li></ul></ul><ul><ul><li>Tabla maestra más copias instantáneas </li></ul></ul><ul><ul><li>Tabla maestra más copias instantáneas actualizables ** </li></ul></ul><ul><ul><li>Especial atención a las secuencias !! </li></ul></ul><ul><ul><li>Especial atencíón a los conflictos de réplica (**) </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

42.
Aspectos a tener en cuenta <ul><li>Diseño de procesos </li></ul><ul><ul><li>Se deberán tener en cuenta, no tan sólo los procesos de réplica y su periodicidad, sino el ancho de banda que consuman, máxime si implican tarificación por paquetes trasnmitidos: </li></ul></ul><ul><ul><ul><li>Pipes y sockets -> Aproximación analítica </li></ul></ul></ul><ul><ul><ul><li>Middleware -> Información a transmitir + Sobrecoste en ancho de banda + Sobrecoste en tiempo de proceso </li></ul></ul></ul><ul><ul><ul><li>Protocolos propietarios (SQL) -> Recurrir a benchmarks o referencias del fabricante </li></ul></ul></ul><ul><ul><li>Analizados los consumos de ancho de banda y tiempo estimado de proceso, se deberá replantear la idoneidad de ubicación de cada proceso </li></ul></ul><ul><ul><li>Extremar las pruebas cuando se requiera diseñar e implementar protocolos de comunicación </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

43.
Aspectos a tener en cuenta <ul><li>Fase de pruebas. Debido a la complejidad del sistema, serán necesarias varias fases: </li></ul><ul><ul><li>Pruebas de funcionalidad de la aplicación. Se puede llevar a cabo sobre máquinas de desarrollo y estaciones de trabajo de forma paralela </li></ul></ul><ul><ul><li>Pruebas de carga del servidor </li></ul></ul><ul><ul><li>Pruebas de integridad de datos. Son especialmente importantes en el caso de bases de datos distribuidas </li></ul></ul><ul><ul><li>Pruebas transaccionales </li></ul></ul><ul><ul><li>Pruebas de red </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

44.
Desarrollos Web <ul><li>Caso particular de desarrollo cliente servidor con representación remota, en la cual disponemos de un protocolo standard: HTTP y un middleware denominado WebServer. </li></ul><ul><li>Cada página puede desencadenar la solicitud de numerosos peticiones adicionales para finalizar el proceso de representación remota. </li></ul><ul><li>Se dispone de un lenguaje standard de definición y formateo de páginas: HTML </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

45.
Desarrollos Web <ul><li>Incrustación de la lógica de aplicación en el servidor Web: </li></ul><ul><ul><li>CGI: Common Gateware Interface </li></ul></ul><ul><ul><ul><li>Cada petición HTTP genera un nuevo proceso, el cual analiza la solicitud y genera un resultado. Cada proceso corresponde a una transacción. </li></ul></ul></ul><ul><ul><ul><li>Es flexible, ideal para pequeñas aplicaciones de uso reducido </li></ul></ul></ul><ul><ul><ul><li>No escala adecuadamente </li></ul></ul></ul><ul><ul><li>Páginas ASP: Caso particular de CGI </li></ul></ul><ul><ul><ul><li>Entorno propietario Microsoft </li></ul></ul></ul><ul><ul><ul><li>Aspectos de rendimiento bastante mejorados </li></ul></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

46.
Desarrollos Web <ul><li>Incrustación de la lógica de aplicación en el servidor Web </li></ul><ul><ul><li>Servlets: Ejecución de aplicaciones Java en el servidor que procesan la petición y generan la página de respuesta </li></ul></ul><ul><ul><ul><li>No generan un proceso adicional por cada petición </li></ul></ul></ul><ul><ul><ul><li>Utilizan un lenguaje de alto nivel (Java) </li></ul></ul></ul><ul><ul><li>Objetos CORBA: </li></ul></ul><ul><ul><ul><li>Pemite la integración de objetos CORBA con el servidor Web, creando una estructura cliente servidor multinivel </li></ul></ul></ul><ul><ul><ul><li>Es la solución más generalista y adaptable </li></ul></ul></ul><ul><ul><ul><li>Permite fácil, flexible y eficiente integración con BBDD </li></ul></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

47.
Desarrollos Web <ul><li>Esquema general </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria Navegador Web Server Servlet Máquina virtual Java Conector CORBA Servidor CORBA Procesos CGI HTTP Parámetros proceso CORBA RMI Base de datos

48.
Nuevos tipos de dispositivos <ul><li>Dispositivos que acceden hoy a internet: </li></ul><ul><ul><li>Internet Explorer, Netscape, Set Top Box, Móviles WAP, PDAs Palm Pilot, Windows CE, ... </li></ul></ul><ul><li>Previsiones para los próximos años: </li></ul><ul><ul><li>2.002 el 50% de las transacciones habituales se podrán realizar desde dispositivos móviles </li></ul></ul><ul><ul><li>2.003 el 80% de los usuarios realizarán algún tipo de transacción desde dispositivos móviles </li></ul></ul><ul><ul><li>2.004 los se querrán realizar el 100% de las transacciones desde dispositivos móviles </li></ul></ul><ul><ul><li>2.005 Se esperan más de 1.000 millones de usuarios móviles de internet </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

49.
Nuevos tipos de dispositivos <ul><li>Problema a resolver: </li></ul><ul><ul><li>Necesidad de adaptar el interface de usuario a cada tipo de dispositivo </li></ul></ul><ul><li>Medidas a tomar: </li></ul><ul><ul><li>Separar la lógica de aplicación del interface de usuario </li></ul></ul><ul><ul><li>Utilizar métodos estándar de comunicación entre la lógica de aplicación y el interface de usuario </li></ul></ul><ul><ul><li>Uso de herramientas que permitan adaptar rápidamente las aplicaciones a los nuevos tipos de dispositivos que irán apareciendo </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

50.
Nuevos tipos de dispositivos <ul><li>Tendencia actual </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria Navegador Web Server Páginas HTML Servidor Aplicaciones Lógica de negocio Datos Interface de usuario Gestor comunicaciones Usuario Móvil WAP Server Páginas WML SQL XML - - Wml binario http Base de datos

51.
Nuevos tipos de dispositivos <ul><li>Variante de los fabricantes BBDD </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria Navegador Web Server Páginas HTML Lógica de negocio Datos Interface de usuario Gestor comunicaciones Usuario Móvil WAP Server Páginas WML XML - - Wml binario http Base de datos

52.
Nuevos tipos de dispositivos <ul><li>Variante de los fabricantes pasarelas </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria Navegador Web Server Páginas HTML Lógica de negocio Datos Interface de usuario Gestor comunicaciones Usuario Móvil WAP Server Reglas de traducción WML SQL - - Wml binario http Interface de usuario Base de datos

53.
Estrategia a seguir <ul><li>Valorar la durabilidad temporal de las tecnologías a aplicar </li></ul><ul><li>Separar, en el diseño e implentación de la aplicación, las capas de lógica de aplicación e interface de usuario </li></ul><ul><li>Prestar mucha atención a los nuevos tipos de dispositivos </li></ul><ul><li>Examinar con lupa los “atajos” ofrecidos por los fabricantes </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

54.
Costes sistema distribuido <ul><li>Elementos a valorar: </li></ul><ul><ul><li>Coste de las comunicaciones: Valorar alternativas presentadas por los nuevos proveedores de telecomunicaciones. No descartar el tirar líneas propias </li></ul></ul><ul><ul><li>Evaluar el coste adicional en hardware, software y gestión que implica una arquitectura distribuida. Si las comunicaciones lo permiten, saldrá más rentable una arquitectura centralizada </li></ul></ul><ul><ul><li>El impacto de los protocolos de comunicaciones será vital en el desglose posterior de costes. Se deben dedicar todos los esfuerzos necesarios para evaluar cuál es el protocolo óptimo. </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

55.
17/03/11 UNAP - Ing. Aldo Zanabria Tecnología de objetos distribuidos y arquitectura de componentes.

56.
17/03/11 UNAP - Ing. Aldo Zanabria Índice 1. Introducción. 2. OMA (Object Management Architecture) . 3. CORBA (Common Object Request Broker Architecture) . 4. Conclusiones.

57.
Introducción 17/03/11 UNAP - Ing. Aldo Zanabria Datos C/S 2 capas Evolución de la arquitectura de los sistemas informáticos Sistemas monolíticos C/S 3 capas BD Negocio Presentación Negocio Presentación Datos Negocio Datos Negocio Presentación

58.
17/03/11 UNAP - Ing. Aldo Zanabria BD Arquitectura multicapa Presentación Negocio Datos subcapas

59.
17/03/11 UNAP - Ing. Aldo Zanabria Arquitectura de componentes (I) (multicapa y 3-tier) 3:Component system 2:Component frameworks 1:Components <ul><li>Tier 1: Arquitectura de componentes individuales. </li></ul><ul><li>Tier 2: Arquitectura de los marcos de componentes. Macro-componentes definidos para realizar una función de negocio concreta. </li></ul><ul><li>Tier 3: Arquitectura del sistema de componentes. Super-componente que define todo el sistema. </li></ul>( tier  grada )

60.
17/03/11 UNAP - Ing. Aldo Zanabria Arquitectura de componentes (II) <ul><li>Cada componente del tier 3 se define con un conjunto de componentes del tier 2, y cada uno del tier 2 por un conjunto del tier 1. </li></ul><ul><li>COMPONENTE = módulo + conjunto de recursos </li></ul><ul><ul><li>Módulo = conjunto de clases y puede que elementos de proceso no orientados a objeto (procedimientos y funciones). </li></ul></ul><ul><ul><li>Conjunto de recursos = múltiples interfaces que cada uno representa un servicio ofrecido por el componente. </li></ul></ul><ul><li>COMPONENTE  OBJETO </li></ul>

61.
17/03/11 UNAP - Ing. Aldo Zanabria <ul><li>Problemas: </li></ul><ul><ul><li>No basta una modelización correcta de jerarquía de clases e interacciones, se necesita una infraestructura (nivel de transporte) de comunicación que permita el flujo transparente de mensajes entre objetos de distintas aplicaciones en distintas máquinas </li></ul></ul><ul><ul><li>Se debe evitar el crecimiento exponencial de interfaces </li></ul></ul><ul><li>Solución: </li></ul><ul><ul><li>Middleware de componentes </li></ul></ul>Arquitectura de componentes (III)

62.
<ul><li>Alternativas: </li></ul><ul><ul><li>Sockets. </li></ul></ul><ul><ul><ul><li>Implementación costosa. </li></ul></ul></ul><ul><ul><li>Remote Procedure Calls ( RPC ). </li></ul></ul><ul><ul><ul><li>No soporta objetos explícitamente. </li></ul></ul></ul><ul><ul><li>Microsoft Distributed Component Object Model ( DCOM ) </li></ul></ul><ul><ul><ul><li>Menos maduro, menos portable y además propietario. </li></ul></ul></ul><ul><ul><li>Java Remote Method Invocation ( RMI ) </li></ul></ul><ul><ul><ul><li>Solo para JAVA. </li></ul></ul></ul><ul><ul><li>Common Object Request Broker Architecture ( CORBA ) </li></ul></ul><ul><ul><ul><li>Multiplataforma, multilenguaje, ... </li></ul></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria Arquitectura de componentes (IV)

63.
OMA (Object Management Architecture) <ul><li>OMG: Object Management Group, Inc. </li></ul><ul><li>http://www.omg.org </li></ul><ul><ul><li>Fundado en 1989. </li></ul></ul><ul><ul><li>Objetivo: Desarrollo de estándares para la reutilización , portabilidad e interoperabilidad de software orientado a objetos en entornos heterogéneos y distribuidos. </li></ul></ul><ul><ul><li>Solución: Definen OMA (Object Management Architecture) de la cual CORBA es una parte. </li></ul></ul><ul><ul><li>Historia: </li></ul></ul><ul><ul><ul><li>1991: CORBA 1.1 </li></ul></ul></ul><ul><ul><ul><li>1995: CORBA 2.0 (Modelo de Referencia) </li></ul></ul></ul><ul><ul><ul><li>2000: CORBA 2.4 (actual) </li></ul></ul></ul><ul><ul><ul><li>2000-2001: CORBA 3.0 (Modelo de Componentes) (en desarrollo) </li></ul></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

64.
OMA: Objetivos técnicos <ul><li>Transparencia distribución </li></ul><ul><li>Rendimiento local y remoto </li></ul><ul><li>Comportamiento dinámico </li></ul><ul><li>Sistema de nombrado </li></ul><ul><li>Consultas: nombre, atributos, relaciones </li></ul><ul><li>Control de la concurrencia </li></ul><ul><li>Transacciones </li></ul><ul><li>Robustez, disponibilidad </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria <ul><li>Mantenimiento de versiones </li></ul><ul><li>Notificación de eventos </li></ul><ul><li>Semántica de Relaciones entre objetos </li></ul><ul><li>API en C para todas las operaciones </li></ul><ul><li>Administración y gestión </li></ul><ul><li>Internacionalización </li></ul><ul><li>Estandarización </li></ul>

65.
Arquitectura del modelo de referencia OMA 17/03/11 UNAP - Ing. Aldo Zanabria Application objects CORBA facilities Object services (CORBAservices) CORBA 2.0 Object Request Broker (ORB)

66.
Object services (CORBAservices) (I) <ul><li>Definen 16 servicios comunes ofrecidos a los objetos: </li></ul><ul><ul><li>Naming service : Identificación de objetos </li></ul></ul><ul><ul><li>Object security service : Servicio de seguridad </li></ul></ul><ul><ul><li>Object trader service : Mercader de objetos. Los ofrece a los clientes. </li></ul></ul><ul><ul><li>Object transaction service : Permite transacciones con commit-rollback </li></ul></ul><ul><ul><li>Change management service : Gestor de versiones de implementación. </li></ul></ul><ul><ul><li>Concurrency service : Gestión de bloqueos para permitir concurrencia </li></ul></ul><ul><ul><li>Event notification service : Objetos que son mensajes de eventos </li></ul></ul><ul><ul><li>Externalization service : Permite copiar objetos por valor </li></ul></ul><ul><ul><li>Licensing service : Permite obtener licencias de uso de un objeto </li></ul></ul><ul><ul><li>Lifecycle service : Crea, copia, mueve y borra objetos y grupos de objetos relacionados </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

67.
Object services (CORBAservices) (II) <ul><ul><li>Object collections service : Crea colecciones de objetos (basado en SMALLTALK) (árboles, listas, colas, conjuntos,...) </li></ul></ul><ul><ul><li>Object query service : Permite localizar los objetos por el valor de sus atributos (parecido al Trader, pero en lugar de servicios ofrece atributos) </li></ul></ul><ul><ul><li>Persistent object service : Permite al objeto sobrevivir a la terminación del programa que lo creó </li></ul></ul><ul><ul><li>Properties service : Asocia propiedades al objeto (modificable, borrable o sólo lectura) </li></ul></ul><ul><ul><li>Relationship service : Permite relaciones entre objetos </li></ul></ul><ul><ul><li>Time service : Soluciona el problema del reloj asíncrono en los SID. Usa time-stamping . </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

68.
CORBAfacilities <ul><li>Definen servicios comunes ofrecidos a las aplicaciones: </li></ul><ul><ul><li>Horizontales: define colecciones de objetos prefabricados </li></ul></ul><ul><ul><ul><li>Interfaz de usuario </li></ul></ul></ul><ul><ul><ul><li>Gestión de la información </li></ul></ul></ul><ul><ul><ul><li>Gestión de sistemas </li></ul></ul></ul><ul><ul><ul><li>Gestión de tareas </li></ul></ul></ul><ul><ul><li>Verticales: define servicios comunes para un dominio completo (framework tier) </li></ul></ul><ul><ul><ul><li>Objetos de negocio </li></ul></ul></ul><ul><ul><ul><li>Comercio electrónico </li></ul></ul></ul><ul><ul><ul><li>Finanzas </li></ul></ul></ul><ul><ul><ul><li>Manufacturación </li></ul></ul></ul><ul><ul><ul><li>Medicina </li></ul></ul></ul><ul><ul><ul><li>Telecomunicaciones </li></ul></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

69.
Application objects <ul><li>Definen servicios específicos de un determinado negocio o aplicación. </li></ul><ul><li>Suponen el nivel más alto de los servicios soportados por la arquitectura OMA </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

70.
CORBA (Common Object Request Broker Architecture) 17/03/11 UNAP - Ing. Aldo Zanabria <ul><li>CORBA es un middleware orientado a objetos / componentes. </li></ul><ul><li>Los objetos cliente solicitan servicios a los objetos servidor mediante invocación de método </li></ul><ul><li>Separa interfaz e implementación </li></ul><ul><li>Es independiente del lenguaje: los objetos clientes y servidores se implementan en cualquier lenguaje (de los soportados) </li></ul><ul><li>Crea transparencia de localización a través del ORB : </li></ul><ul><ul><li>de objetos: la invocación siempre se hace en local </li></ul></ul><ul><ul><li>de red: el ORB la gestiona </li></ul></ul><ul><ul><li>de activación: los servidores se activan automáticamente </li></ul></ul><ul><ul><li>de estado persistente: permite que el servidor guarde persistencia y es transparente al cliente </li></ul></ul>

71.
IDL (Interface Definition Language) <ul><li>CORBA incorpora un lenguaje de definición de interfaces (IDL) </li></ul><ul><li>Independiente del lenguaje de implementación. </li></ul><ul><li>Mapea hacia los lenguajes de programación habituales. </li></ul><ul><li>Los ORBs llevan incorporados su traductor de IDL a los lenguajes de implementación soportados </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria C C++ Ada Java IDL SmallTalk Object Request Broker (ORB) Delphi

72.
17/03/11 UNAP - Ing. Aldo Zanabria Comunicación C/S en CORBA Cliente Servidor Object Request Broker (ORB) Invocation Interface Object Adapter

73.
17/03/11 UNAP - Ing. Aldo Zanabria Object Request Broker (ORB) Arquitectura de CORBA Dynamic Invocation Interface IDL Stubs ORB Interface IDL Static Skeletons Dynamic Skeleton Interface Object Adapter Interface Repository IDL COMPILER Implementation Repository Client Object (Servant) OBJ REF operación(args) resultado(args)

74.
17/03/11 UNAP - Ing. Aldo Zanabria Componentes primarios en CORBA (I) <ul><li>Object : </li></ul><ul><ul><li>Entidad de programación CORBA. </li></ul></ul><ul><ul><li>Tiene una identidad, una interfaz, y una implementación (conocida como Servant). </li></ul></ul><ul><li>Servant (sirviente) : </li></ul><ul><ul><li>Implementación de una entidad en un lenguaje de programación (en cualquiera de los soportados). </li></ul></ul><ul><ul><li>Define las operaciones que soporta un determinado interfaz CORBA IDL. </li></ul></ul><ul><li>Client : </li></ul><ul><ul><li>Entidad de programa que invoca una operación a una implementación de objeto. </li></ul></ul><ul><ul><li>Idealmente será tan simple como una invocación a un método. </li></ul></ul><ul><li>Object Request Broker (ORB) (corredor de peticiones a objetos) : </li></ul><ul><ul><li>Núcleo de la arquitectura CORBA. </li></ul></ul><ul><ul><li>Proporciona transparencia entre los clientes y las implementaciones de los objetos. </li></ul></ul><ul><ul><li>Cuando un cliente invoca una operación, ORB busca la implementación del objeto, lo activa si es necesario, transmite la petición y devuelve la respuesta. </li></ul></ul><ul><ul><li>Permite conexión con otros ORBs. </li></ul></ul>

75.
17/03/11 UNAP - Ing. Aldo Zanabria Componentes primarios en CORBA (II) <ul><li>ORB Interface : </li></ul><ul><ul><li>Interfaz de comunicación con el ORB para solicitarle servicios al propio ORB: conversión de referencias de objetos a cadenas, ... </li></ul></ul><ul><li>IDL stubs (cabos) : </li></ul><ul><ul><li>El stub es la interfaz que ve el cliente </li></ul></ul><ul><ul><li>Representante del servidor en el lado cliente (proxy) </li></ul></ul><ul><ul><li>Realiza invocación remota </li></ul></ul><ul><ul><li>Define rutinas específicas para operaciones particulares en objetos particulares </li></ul></ul><ul><ul><li>Definido en IDL y se transforma al lenguaje de programación del Cliente </li></ul></ul><ul><ul><li>La transformación entre CORBA IDL y el lenguaje de programación se realiza automáticamente por el IDL compiler </li></ul></ul><ul><li>IDL skeletons (esqueletos) : </li></ul><ul><ul><li>Ofrece una interfaz estática a cada servicio del objeto </li></ul></ul><ul><ul><li>Definido en IDL y se transforma al lenguaje de programación del Servant </li></ul></ul>

76.
17/03/11 UNAP - Ing. Aldo Zanabria Componentes primarios en CORBA (III) <ul><li>Dynamic Invocation Interface : </li></ul><ul><ul><li>Permite la construcción dinámica de invocaciones a objetos. </li></ul></ul><ul><ul><li>No llama a una rutina específica para una operación particular en un objeto particular. </li></ul></ul><ul><ul><li>El cliente especifica el objeto a ser invocado, la operación y el conjunto de parámetros (esto lo obtiene del Interface Repository) </li></ul></ul><ul><li>Dynamic Skeleton Interface : </li></ul><ul><ul><li>Permite el manejo dinámico de las invocaciones a objetos. </li></ul></ul><ul><ul><li>No es accedido por un esqueleto específico para una operación determinada. </li></ul></ul><ul><ul><li>Se proporciona acceso a través de un nombre de operación y parámetros. </li></ul></ul>

77.
17/03/11 UNAP - Ing. Aldo Zanabria Componentes primarios en CORBA (IV) <ul><li>Object Adapter : </li></ul><ul><ul><li>Conecta al ORB con la implementación del objeto para realizar los servicios que el ORB proporciona (a otros objetos y clientes): </li></ul></ul><ul><ul><ul><li>generación e interpretación de referencias a objetos </li></ul></ul></ul><ul><ul><ul><li>invocación de métodos </li></ul></ul></ul><ul><ul><ul><li>seguridad de las interacciones </li></ul></ul></ul><ul><ul><ul><li>activación y desactivación del objeto y su implementación </li></ul></ul></ul><ul><ul><ul><li>mapeo de las referencias de los objetos a sus implementaciones </li></ul></ul></ul><ul><ul><ul><li>registro de implementaciones. </li></ul></ul></ul>

78.
17/03/11 UNAP - Ing. Aldo Zanabria Componentes primarios en CORBA (V) <ul><li>Interface Repository : </li></ul><ul><ul><li>Almacena información relativa a las interfaces IDL definidas en el Sistema Distribuido. </li></ul></ul><ul><ul><li>El ORB solicita los servicios al IR para: </li></ul></ul><ul><ul><ul><li>comunicarse con otros ORB de distinta implementación. </li></ul></ul></ul><ul><ul><ul><li>verificar los parámetros de la petición </li></ul></ul></ul><ul><ul><ul><li>verificar la existencia de ciclos en los grafos de herencia </li></ul></ul></ul><ul><ul><li>Los clientes solicitan los servicios al IR para: </li></ul></ul><ul><ul><ul><li>navegar por la lista de interfaces </li></ul></ul></ul><ul><ul><ul><li>facilitar la instalación y distribución de objetos </li></ul></ul></ul><ul><ul><li>Un ORB puede tener varios IR según la necesidad (prueba, release, externos, ... </li></ul></ul><ul><li>Implementation Repository : </li></ul><ul><ul><li>Almacena información de administración de cada uno de los objetos: cuáles están instanciados, como activarlos, permisos, etc. </li></ul></ul>

79.
17/03/11 UNAP - Ing. Aldo Zanabria Conclusiones <ul><li>Independiente del Sistema Operativo y del lenguaje de programación </li></ul><ul><li>Intenta hacer transparente a los programadores todos los aspectos que sea posible. </li></ul><ul><li>Facilita la reutilización de software, incluso cuando no esté implementado en un OOL. </li></ul><ul><li>Incorpora mecanismos de seguridad: autentificación, encriptación,... </li></ul><ul><li>Tecnología OO. </li></ul><ul><li>Estándar comercial y abierto. </li></ul><ul><li>CORBA 3.0 Modelo de componentes (CCM) </li></ul>

80.
17/03/11 UNAP - Ing. Aldo Zanabria Seguridad en el SID. INTERNET E INTRANET

81.
OBJETIVOS <ul><li>Identificar problemas de seguridad en los SID. </li></ul><ul><li>Estudiar las características de los cortafuegos y aprender a seleccionarlos. </li></ul><ul><li>Funciones de los cortafuegos en Internet e Intranet. </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

82.
17/03/11 UNAP - Ing. Aldo Zanabria ÍNDICE 1. Riesgos y amenazas. 2. El cortafuegos. 3. Administración de cortafuegos. 4. Políticas de seguridad.

83.
17/03/11 UNAP - Ing. Aldo Zanabria MODELO DE RED CORPORATIVA

84.
FACTORES DE RIESGO <ul><li>Tipos de activos a proteger (datos confidenciales, programas susceptibles de sufrir sabotajes). </li></ul><ul><li>Probabilidad de sufrir un ataque: conocimiento de la posibilidad de existencia de entidades ajenas intrusas. </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

85.
MECANISMOS PARA LA VALORACIÓN DE RIESGOS <ul><li>Equipos de “tigres”: ataques simulados. </li></ul><ul><li>Sesiones creativas de especialistas. </li></ul><ul><li>Procesos de ingeniería de seguridad de sistemas: análisis de la arquitectura, identificación de amenazas, integración de la protección. </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

86.
RIESGOS EN LA INTRANET 17/03/11 UNAP - Ing. Aldo Zanabria

87.
RIESGOS EN INTERNET 17/03/11 UNAP - Ing. Aldo Zanabria

88.
VALORACIÓN DE RIESGOS <ul><li>Confidencialidad de mis datos. </li></ul><ul><li>Atractivo de activos. </li></ul><ul><li>Características de mi conexión Internet. </li></ul><ul><li>Características de mis routers. </li></ul><ul><li>Presupuesto de seguridad. </li></ul><ul><li>Uso de la criptografía. </li></ul><ul><li>Valorar el nivel de nuestro personal informático. </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

89.
EL CORTAFUEGOS <ul><li>Definición: medio de regulación del acceso a la red de ordenadores de una organización mediante el control de accesos y el registro de actividades. </li></ul><ul><li>Función principal: limitar acceso a la Intranet filtrando los paquetes entrantes (por medio de la información que contienen). </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

90.
CARACTERÍSTICAS DEL CORTAFUEGOS <ul><li>Registro de actividades: información de sesiones (paquetes, fecha). </li></ul><ul><li>Sistema de aviso de intrusiones. </li></ul><ul><li>Ubicado de tal forma que las comunicaciones pasen a través suyo. </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

91.
UBICACIÓN DE CORTAFUEGOS 17/03/11 UNAP - Ing. Aldo Zanabria

92.
TIPOS DE CORTAFUEGOS <ul><li>Filtrado de paquetes: generalmente, routers. Se hace a nivel de red (poco seguros). </li></ul><ul><li>Gateways a nivel de aplicación: programas. Las conexiones se canalizan a través de aplicaciones proxy. </li></ul><ul><li>Híbridos: combina los dos anteriores. </li></ul><ul><li>Host bastión: arquitectura más que tipo de cortafuegos. Aisla la LAN. </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

93.
¿CÓMO SE FILTRAN LOS PAQUETES? <ul><li>Se especifican reglas de filtrado, y acciones asociadas a ellas. </li></ul><ul><li>En ellas consta: número de regla, dirección origen, destino, protocolo, puerto origen y destino y acción. </li></ul><ul><li>Importante: el orden de las reglas. </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

94.
FILTROS SOFTWARE <ul><li>Filtrado de sesiones: </li></ul><ul><li>se realiza generalmente en el kernel del S.O. </li></ul><ul><li>Una sola regla para cada sesión. </li></ul><ul><li>Aplicaciones Proxy: </li></ul><ul><li>programas que se sitúan en el cortafuegos y actúan en representación del usuario. </li></ul><ul><li>Conexiones: directa, cliente modificado y proxy invisible. </li></ul><ul><li>Desventaja: una aplicación por servicio </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

95.
AUTENTIFICACIÓN DE USUARIOS <ul><li>Contraseñas: un solo uso (cambia cada sesión por algoritmos criptográficos) y uso múltiple (pueden ser “pinchadas”). </li></ul><ul><li>Tarjetas inteligentes o llaves (autentificadores manuales): se solicita palabra de paso y clave, y se devuelve contraseña. </li></ul><ul><li>Huellas dactilares y modelos de retina. </li></ul><ul><li>Problema de todos ellos: secuestros de sesión. Solución: autentificación de paquetes. </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

96.
ADMINISTRACIÓN DEL CORTAFUEGOS <ul><li>Mantener las cuentas de usuarios. </li></ul><ul><li>Actualizar permisos de acceso a hosts. </li></ul><ul><li>Reaccionar ante alarmas. </li></ul><ul><li>Revisar registros de actividad. </li></ul><ul><li>Hacer copias de seguridad de los datos del cortafuegos. </li></ul><ul><li>Mantenimiento del sistema del cortafuegos. </li></ul><ul><li>Información sobre tecnología de ataques. </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

97.
TRAMPAS Y CEBOS <ul><li>Sirven para atraer atacantes sospechosos. </li></ul><ul><li>Determinar tipos de acceso intrusos. </li></ul><ul><li>Crear entorno ficticio y legal (avisar al usuario que está accediendo a la red). </li></ul><ul><li>Obtener información para demandar al atacante (tener cuidado con no transgredir la ley nosotros). </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

98.
RESPUESTA A UN ATAQUE (1) <ul><li>Mantener la calma (normalmente es inofensivo). </li></ul><ul><li>¿Interrumpimos el ataque?. </li></ul><ul><li>Sí: destruir la conexión y desconectar el cortafuegos. </li></ul><ul><li>No: detectar al intruso (leer registro de auditoría, obtener lista de routers hasta el intruso, identificar usuarios actuales). </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

99.
RESPUESTA A UN ATAQUE (Y 2) <ul><li>Una vez finalizado el ataque: </li></ul><ul><li>Determinar los cambios a efectuar en la política de seguridad. </li></ul><ul><li>Documentar detalles del ataque. </li></ul><ul><li>Informar al proveedor del cortafuegos, y a las autoridades (si procede). </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

100.
POLÍTICA DE SEGURIDAD <ul><li>Definición: especificación de los requisitos de control de acceso a la información y otros activos de una organización, determinando el tipo de acceso (consulta, modificación, borrado, descarga etc.) y quiénes lo realizan. </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

101.
TIPOS DE POLÍTICAS DE SEGURIDAD <ul><li>Política de acceso en el ámbito de los servicios: define los requisitos de control de acceso a usuarios. (Alto nivel). </li></ul><ul><li>Política de acceso en el ámbito de implementación de la red: definición de las reglas de filtrado del cortafuegos. (Bajo nivel). </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

102.
POSIBLES PROBLEMAS <ul><li>Suponen un retraso en la implantación de las protecciones en la red. </li></ul><ul><li>Burocracia: entran en los trabajos cotidianos de operación del sistema. </li></ul><ul><li>Hay que velar por el cumplimiento de la política para que sea efectiva. </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

103.
REQUISITOS PARA UNA CORRECTA POLÍTICA <ul><li>Determinar permisos para servicios de entrada (TELNET, correo etc.) </li></ul><ul><li>Determinar permisos para servicios de salida (WWW, FTP etc.) </li></ul><ul><li>Determinar requisitos de auditoría: disminuyen rendimiento de la red. </li></ul><ul><li>Elegir herramienta de administración. </li></ul><ul><li>Requisitos para cebos y trampas: no salirse de la ley. </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

104.
EJEMPLO (1) <ul><li>Propuesto por Ed Amoroso y Ron Sharp. </li></ul><ul><li>a) Puntos principales de contacto (personas). </li></ul><ul><li>b) Registro de modificaciones (versiones de la política). </li></ul><ul><li>c) Ámbito de los requisitos: definición de la red. </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

105.
EJEMPLO (Y 2) <ul><li>d) Clasificación de la información de la empresa (abierta, propietaria y propietaria restringida). </li></ul><ul><li>e) Clasificación de las redes de la empresa: abierta, propietaria y propietaria - restringida. </li></ul><ul><li>f) Servicios del cortafuegos: acceso o no a Telnet, FTP, EMAIL, WWW. </li></ul>17/03/11 UNAP - Ing. Aldo Zanabria

106.
REAL DECRETO 994/1999, de 11 de junio (B.O.E. 25.06.1999) <ul><li>http://www.igsap.map.es:80/cia/dispo/rd994-99.htm </li></ul><ul><li>Establece 3 niveles de seguridad: </li></ul><ul><ul><li>a) BÁSICO: datos de carácter personal </li></ul></ul><ul><ul><li>b) INTERMEDIO: datos de infracciones administrativas, penales, servicios financieros, o personales que permitan evaluación de personalidad del individuo. </li></ul></ul><ul><ul><li>c) ALTO: datos de ideología, religión, creencias, raza, salud, vida sexual y política. </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

107.
REAL DECRETO 994/1999. Requisitos <ul><li>Nivel BÁSICO: </li></ul><ul><ul><li>Documento de seguridad con la normativa básica. </li></ul></ul><ul><ul><li>Mecanismos de actualización y revisión de la normativa. </li></ul></ul><ul><ul><li>Documento de funciones y obligaciones del personal. </li></ul></ul><ul><ul><li>Medidas para informar al personal sobre la normativa. </li></ul></ul><ul><ul><li>Registro de incidencias. </li></ul></ul><ul><ul><li>Relación de usuarios y procedimientos de identificación y autentificación. </li></ul></ul><ul><ul><li>Renovación periódica de contraseñas y almacenamiento ininteligible. </li></ul></ul><ul><ul><li>Mecanismos para evitar intrusiones no autorizadas. </li></ul></ul><ul><ul><li>Control de soportes (inventario). </li></ul></ul><ul><ul><li>Control de salidas de soportes. </li></ul></ul><ul><ul><li>Copias de respaldo, al menos semanalmente. </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

108.
REAL DECRETO 994/1999. Requisitos (2) <ul><li>Nivel INTERMEDIO: </li></ul><ul><ul><li>Todo el básico. </li></ul></ul><ul><ul><li>Documento de seguridad ampliado. </li></ul></ul><ul><ul><li>Designación de responsables de seguridad. </li></ul></ul><ul><ul><li>Consignación de recuperaciones en incidencias. </li></ul></ul><ul><ul><li>Autorización escrita del responsable para recuperar ficheros. </li></ul></ul><ul><ul><li>Identificación unívoca de usuarios. </li></ul></ul><ul><ul><li>Limitación de accesos no autorizados reincidentes. </li></ul></ul><ul><ul><li>Control de acceso físico. </li></ul></ul><ul><ul><li>Registro de entrada y salida de soportes. </li></ul></ul><ul><ul><li>Mecanismo para impedir recuperaciones de información almacenada en soportes. </li></ul></ul><ul><ul><li>Auditorías informáticas cada 2 años. </li></ul></ul><ul><ul><li>Pruebas con datos ficticios. </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria

109.
REAL DECRETO 994/1999. Requisitos (y 3) <ul><li>Nivel ALTO: </li></ul><ul><ul><li>Todo el intermedio. </li></ul></ul><ul><ul><li>Copias de respaldo y recuperación fuera de las instalaciones de equipos informáticos. </li></ul></ul><ul><ul><li>Cifrado de la información de los soportes. </li></ul></ul><ul><ul><li>Registro de accesos. </li></ul></ul><ul><ul><li>Informe mensual de revisiones y problemas detectados. </li></ul></ul><ul><ul><li>Transmisión cifrada de datos. </li></ul></ul>17/03/11 UNAP - Ing. Aldo Zanabria