sistemas de información distribuidos
Post on 13-Jun-2015
4.337 Views
Preview:
DESCRIPTION
TRANSCRIPT
13/04/23 UNAP - Ing. Aldo Zanabria 1
Sistemas de Información Distribuidos
Ing. Aldo Zanabria Gálvez
UNAP Puno. 2010
9no Semestre – Ingeniería de Sistemas
13/04/23 UNAP - Ing. Aldo Zanabria 2
Arquitectura Cliente/Servi
dor
13/04/23 UNAP - Ing. Aldo Zanabria 3
Justificación Cliente/ServidorANTES AHORA
AVANCETECNOLÓGICO
Rigidez. No redistribución. Vinculación al sistema. Solapamiento,
duplicación yredundancia.
Múltiplesprocesadores
Portabilidad entreprocesadores.
Migrabilidad entreplataformas.
EXIGENCIASDE LAEMPRESA
Producción masiva. Tareas simples. Repetitivas. Desmotivación. Usuario operador.
Competencia. Renovación. Factor tiempo crítico. Autonomía. Usuario analista.
ENTORNOGENERAL
Adaptación a lacapacidad delordenador.
Ordenadores caros. Usuarios asustadizos.
Software a medida. Ordenadores
accesibles. Domesticación de la
informática.
13/04/23 UNAP - Ing. Aldo Zanabria 4
Nuevas Tareas del Dpto. de Sistemas de Información Soporte a la gestión empresarial. Apoyo a los objetivos. Selección de Estándares:
Compatibiliza. Facilita al usuario.
Infraestructura C/S: Plataforma operativa. Entorno de desarrollo. Gestión del SID. Arquitectura de la aplicación:
Portabilidad. Interoperatividad. Distribuida.
Desarrollo corporativo (no departamental). Integración de aplicaciones propias con estándar.
13/04/23 UNAP - Ing. Aldo Zanabria 5
Implicaciones del modelo Cliente/Servidor
N u evo p roceso d e d esarro llo
N u evas h erram ien tas d e d esarro llo :P ro to tip os
N u evos ro les d e S is tem as d eIn fo rm ac ió n y d e los u su arios
In fraes tru c tu ra A b ie rtaC lien te /S ervid or
N eces id ad es com erc ia les en con tin u a evo lu c ió n
13/04/23 UNAP - Ing. Aldo Zanabria 6
¿Cuándo implantar C/S?
Cambios estructurales y organizativos. Cambios en organigramas. Respuesta dinámica de mercado. Cambio en procesos de negocio.
13/04/23 UNAP - Ing. Aldo Zanabria 7
¿Qué ayuda a la implantación? La demanda de sistemas fáciles. Precio/rendimiento de estaciones y
servidores. Creciente acceso a la información para
decisiones: Separación datos-programas. Programas flexibles.
Nuevas tecnologías de alta productividad.
13/04/23 UNAP - Ing. Aldo Zanabria 8
Cliente/Servidor
Definición: Sistema distribuido entre múltiples procesadores donde hay clientes que solicitan servicios y servidores que los proporcionan.
Separa los servicios situando cada uno en su plataforma más adecuada.
13/04/23 UNAP - Ing. Aldo Zanabria 9
Objetivos de C/S
Localización transparente. Recursos compartidos. Escalabilidad
Horizontal: > nº estaciones. Vertical: migración a otras plataformas.
Interoperatividad entre distintos Hw. y Sw.
13/04/23 UNAP - Ing. Aldo Zanabria 10
Evolución
1ª ÉPOCA: LAN. LAN con MAINFRAMES. Comunicaciones homogéneas (LU, SNA, APPC).
2ª ÉPOCA: Herramientas de desarrollo C/S. Proveedores DBMS con C/S. Downsizing: migración a PCs. S.O. De red con servidores de servicios.
13/04/23 UNAP - Ing. Aldo Zanabria 11
Evolución (II)
3ª ÉPOCA: ACTUAL. PWS: Estaciones de trabajo programables gráficamente. GUI: Interfaz gráfico de usuario. Alta resolución. Nuevas tecnologías: Ratón, lápiz óptico, scanner, multimedia. Tecnología de componentes: DDE y OLE. Conectividad de BDs: ODBC, JDBC Objetos Distribuidos: CORBA, COM, COM+, DCOM Internet: HTML, CGI, Applet, ActiveX, JAVA, JAVASCRIPT Arquitecturas C/S de 2 y 3 niveles. Middleware.
13/04/23 UNAP - Ing. Aldo Zanabria 12
Tecnología de componentes: DDE y OLE
DDE: (Dynamic Data Exchange) (Microsoft). Enlaces de datos dinámicos. Información automáticamente actualizada entre
aplicaciones. OLE: (Object Linking and Embeding) (Microsoft).
Objetos enlazados y embebidos. Enlazado: Guardando una referencia. Embebido: Insertando un documento.
13/04/23 UNAP - Ing. Aldo Zanabria 13
Conectividad de BDs
ODBC: (Open DataBase Conectivity) (Microsoft). Conectividad abierta entre BDs. Interfaz de conexión entre BDs (especialmente
Microsoft)
JDBC: (Java DataBase Conectivity) (Java). Conectividad abierta entre BDs versión Java. Abierto.
13/04/23 UNAP - Ing. Aldo Zanabria 14
Objetos Distribuidos
CORBA (Common Object Request Broker Architecture) (Object Management Group): Estándar de programación distribuida basada en objetos.
COM (Microsoft): Interface estándar para objetos (no importa cómo están programados).
COM+ (Microsoft): Extensión de COM en el que se añade un modelo para la programación de objetos.
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.
13/04/23 UNAP - Ing. Aldo Zanabria 15
INTERNET 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.
CGI (Common Gateway Interface): Interface para el tratamiento de ejecutables en el servidor (remoto) a petición de clientes. Rápido y muy modular.
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.
JAVA (Sun Microsystems): Lenguaje de programación específico para C/S en internet. Lento, con aplicaciones mayores.
APPLET: Objetos visuales embebidos en una página web (versión abierta de ActiveX).
JAVABEANS (Sun Microsystems): Especificación para objetos en Java. JAVASCRIPT (Netscape): Lenguaje de utilidades para HTML.
13/04/23 UNAP - Ing. Aldo Zanabria 16
Evolución (III)
EL FUTURO. Facilidad de uso de las aplicaciones. Accesos a datos distribuidos en cualquier lugar del mundo
(y del espacio).
13/04/23 UNAP - Ing. Aldo Zanabria 17
MIDDLEWARE
Conecta procesos para constituir aplicación. Conjunto de funciones + servicios. Actúa en el bajo nivel del SID:
Comunicación. Directorios. Integridad.
Define la plataforma de transparencia de localización.
13/04/23 UNAP - Ing. Aldo Zanabria 18
Características C/S.
Flexibilidad: Middleware. Separación de funciones:
Lógica de presentación. Lógica de negocio. Lógica de datos.
Encapsulación de servicios. Portabilidad - reubicación. Operación sincrono - asíncrono.
13/04/23 UNAP - Ing. Aldo Zanabria 19
Características C/S (II).
Entorno de aplicaciones incremental. Añadir un nuevo servidor. Añadir un nuevo cliente. Modificar un cliente para usar un nuevo servidor.
Integración: por la GUI.
13/04/23 UNAP - Ing. Aldo Zanabria 20
Modelos C/S
Presentación distribuida Proporciona un API que separa la programación
de ventanas del resto. Ejemplo: X-Windows System en UNIX o
Windows95 y NT.
Presentación Negocio Datos
C S
13/04/23 UNAP - Ing. Aldo Zanabria 21
Modelos C/S (II)
Función distribuida Máxima flexibilidad. Lógicas de negocio separadas.
Presentación Negocio DatosNegocio
C S
13/04/23 UNAP - Ing. Aldo Zanabria 22
Modelos C/S (III)
Datos distribuidos Ficheros distribuidos. Bases de datos distribuidas.
Presentación Negocio Datos
C S
13/04/23 UNAP - Ing. Aldo Zanabria 23
Aplicaciones de 2 y 3 niveles
2 niveles: Generalmente usa los modelos de función
distribuida o datos distribuidos. Muy productivo. Distribución no flexible. Dependiente del suministrador.
13/04/23 UNAP - Ing. Aldo Zanabria 24
Aplicaciones de 2 y 3 niveles (II) 3 niveles:
Modelo presentación-negocio-datos Distribución flexible. Sistema abierto. No dependiente.
C
C
C
Negocio
13/04/23 UNAP - Ing. Aldo Zanabria 25
Sistemas abiertos
Definición según IEEE: “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”.
Definición según ISO:“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”
13/04/23 UNAP - Ing. Aldo Zanabria 26
Sistemas Abiertos: Características. Elección libre de plataforma gracias a la portabilidad
e interoperatividad. Protección de la inversión empresarial. Libertad de elección del modelo de distribución:
presentación, función o datos distribuidos. Explotación de aplicaciones estándar.
13/04/23 UNAP - Ing. Aldo Zanabria 27
Estándares
Definición: “Conjunto de reglas, definiciones y propiedades mutuamente aceptadas que permite la cooperación de objetos heterogéneos y su utilización”
Clasificación: Por su lugar de publicación:
Internacional Regional (CEE). Nacional.
Por autor: De Iure: por comité De facto: por fabricante.
13/04/23 UNAP - Ing. Aldo Zanabria 28
Sistemas abiertos vs propietarios Tiempo de implantación mayor en abiertos:
Estándar 10 años. Alianzas y consorcios (no oficial): medio plazo. Tecnologías propietarias portables: corto plazo. Tecnologías propietarias: Rápidas. No abiertas.
Diferenciador de producto: Estándar industrial + algo propio. Ejemplo: un DBMS con SQL estándar + 4GL propio.
Arquitecturas de proveedores importantes.
13/04/23 UNAP - Ing. Aldo Zanabria 29
Sistemas Abiertos: Factores de éxito.
Independencia del suministrador. Elección de herramientas:
Interoperativas: Estándares. Portables: Estándar o propietario.
Arquitectura de la aplicación: Buen diseño C/S.
13/04/23 UNAP - Ing. Aldo Zanabria 30
Plataformas operativas: Gestores de recursos Definición: ”Programas software que acceden a
recursos (dispositivos, ficheros, bases de datos, programas, objetos, etc.) y proporcionan un API”.
Tipos: Local: servicio en s.o. local. Remoto: con C/S. Distribuido: en varios lugares.
13/04/23 UNAP - Ing. Aldo Zanabria 31
Plataformas operativas: Middleware
Función de intermediario entre clientes y servidores. Otros servicios:
Directorio de recursos: info. sobre ellos. Nominación de recursos. Comunicaciones:
Conversacional (SINC) RPC: (SINC) Cola de mensajes: (ASINC)
Seguridad: Login único. Gestión de transacciones: única para todos los recursos.
13/04/23 UNAP - Ing. Aldo Zanabria 32
Selección de sw C/S
Sistema operativo. Múltiples modelos de distribución C/S. Nuevas tecnologías (POO). Apertura. Integración con sw estándar. Operación C/S (síncrona y asíncrona). Herramientas de desarrollo potentes.
13/04/23 UNAP - Ing. Aldo Zanabria 33
Ejercicios:
13/04/23 UNAP - Ing. Aldo Zanabria 34
Ejercicio 1
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:
a) ¿Podríamos estar ante un sistema distribuido? b) ¿Es razonable esta forma de trabajar? ¿Por qué? c) ¿Es mejorable? ¿Cómo?
13/04/23 UNAP - Ing. Aldo Zanabria 35
Ejercicio 2
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é?
13/04/23 UNAP - Ing. Aldo Zanabria 36
CONSIDERACIONES:
Aspectos a considerar, tendencias, Desarrollo web, nuevos tipos de dispositivos.
13/04/23 UNAP - Ing. Aldo Zanabria 37
Aspectos a tener en cuenta en el proceso de ingeniería Protocolos de comunicaciones:
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: Pipes RPC SQL Remoto HTTP X11 Otros
13/04/23 UNAP - Ing. Aldo Zanabria 38
Aspectos a tener en cuenta
Middleware. Es la herramienta o conjunto de herramientas que nos permitiran gestionar y coordinar los mecanismos de comunicación. Independiza el servicio y su implementación, del
S.O. y protocolos de comunicaciones Permite la convivencia de distintos servicios en
una misma máquina Modelo tradicional: Monitor de teleproceso
CICS, Tuxedo, Encina Modelo OO: CORBA
13/04/23 UNAP - Ing. Aldo Zanabria 39
Aspectos a tener en cuenta
Fase de análisis: Prácticamente no hay diferencias respecto a un
S.I. tradicional Se debe definir la política de empresa: fat client o
fat server. Se debe definir el coste en comunicaciones que
puede asumir la organización.
13/04/23 UNAP - Ing. Aldo Zanabria 40
Aspectos a tener en cuenta
Fase de diseño El diseño de entidades, en raras ocasiones se
verán éstas afectadas Aparecerán nuevos conjuntos de datos en los
DFDs. No se trata de nuevas entidades, sino de información que debe viajar entre nodos
Respecto al diseño de tablas, se debe especificar su implementación: Desde qué nodos debe ser accesible Qué nivel de acceso se precisa desde cada uno de ellos Cómo implementarlo
13/04/23 UNAP - Ing. Aldo Zanabria 41
Aspectos a tener en cuenta
Implementación BB.DD. Distribuidas No hay entornos puramente distribuidos. Debe analizarse,
tabla a tabla, qué distribuir, qué centralizar y cómo hacerlo: Tabla única Tablas con réplica simétrica on-line Tablas con réplica simétrica off-line ** Tabla maestra más copias instantáneas Tabla maestra más copias instantáneas actualizables ** Especial atención a las secuencias !! Especial atencíón a los conflictos de réplica (**)
13/04/23 UNAP - Ing. Aldo Zanabria 42
Aspectos a tener en cuenta
Diseño de procesos 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: Pipes y sockets -> Aproximación analítica Middleware -> Información a transmitir + Sobrecoste en ancho
de banda + Sobrecoste en tiempo de proceso Protocolos propietarios (SQL) -> Recurrir a benchmarks o
referencias del fabricante Analizados los consumos de ancho de banda y tiempo estimado de
proceso, se deberá replantear la idoneidad de ubicación de cada proceso
Extremar las pruebas cuando se requiera diseñar e implementar protocolos de comunicación
13/04/23 UNAP - Ing. Aldo Zanabria 43
Aspectos a tener en cuenta
Fase de pruebas. Debido a la complejidad del sistema, serán necesarias varias fases: Pruebas de funcionalidad de la aplicación. Se puede
llevar a cabo sobre máquinas de desarrollo y estaciones de trabajo de forma paralela
Pruebas de carga del servidor Pruebas de integridad de datos. Son especialmente
importantes en el caso de bases de datos distribuidas Pruebas transaccionales Pruebas de red
13/04/23 UNAP - Ing. Aldo Zanabria 44
Desarrollos Web
Caso particular de desarrollo cliente servidor con representación remota, en la cual disponemos de un protocolo standard: HTTP y un middleware denominado WebServer.
Cada página puede desencadenar la solicitud de numerosos peticiones adicionales para finalizar el proceso de representación remota.
Se dispone de un lenguaje standard de definición y formateo de páginas: HTML
13/04/23 UNAP - Ing. Aldo Zanabria 45
Desarrollos Web
Incrustación de la lógica de aplicación en el servidor Web: CGI: Common Gateware Interface
Cada petición HTTP genera un nuevo proceso, el cual analiza la solicitud y genera un resultado. Cada proceso corresponde a una transacción.
Es flexible, ideal para pequeñas aplicaciones de uso reducido No escala adecuadamente
Páginas ASP: Caso particular de CGI Entorno propietario Microsoft Aspectos de rendimiento bastante mejorados
13/04/23 UNAP - Ing. Aldo Zanabria 46
Desarrollos Web
Incrustación de la lógica de aplicación en el servidor Web Servlets: Ejecución de aplicaciones Java en el servidor
que procesan la petición y generan la página de respuesta No generan un proceso adicional por cada petición Utilizan un lenguaje de alto nivel (Java)
Objetos CORBA: Pemite la integración de objetos CORBA con el servidor Web,
creando una estructura cliente servidor multinivel Es la solución más generalista y adaptable Permite fácil, flexible y eficiente integración con BBDD
13/04/23 UNAP - Ing. Aldo Zanabria 47
Desarrollos Web
Esquema general Navegador
Web Server
ServletMáquina virtual
Java
ConectorCORBA
ServidorCORBA
Procesos CGI
HTTP
Parámetrosproceso
CORBA
RMIBase de datos
13/04/23 UNAP - Ing. Aldo Zanabria 48
Nuevos tipos de dispositivos Dispositivos que acceden hoy a internet:
Internet Explorer, Netscape, Set Top Box, Móviles WAP, PDAs Palm Pilot, Windows CE, ...
Previsiones para los próximos años: 2.002 el 50% de las transacciones habituales se
podrán realizar desde dispositivos móviles 2.003 el 80% de los usuarios realizarán algún tipo de
transacción desde dispositivos móviles 2.004 los se querrán realizar el 100% de las
transacciones desde dispositivos móviles 2.005 Se esperan más de 1.000 millones de usuarios
móviles de internet
13/04/23 UNAP - Ing. Aldo Zanabria 49
Nuevos tipos de dispositivos Problema a resolver:
Necesidad de adaptar el interface de usuario a cada tipo de dispositivo
Medidas a tomar: Separar la lógica de aplicación del interface de usuario Utilizar métodos estándar de comunicación entre la lógica
de aplicación y el interface de usuario Uso de herramientas que permitan adaptar rápidamente
las aplicaciones a los nuevos tipos de dispositivos que irán apareciendo
13/04/23 UNAP - Ing. Aldo Zanabria 50
Nuevos tipos de dispositivos Tendencia actual
Navegador
Web Server
Páginas HTML
Servidor Aplicaciones Lógica de negocio
DatosBase de datos
Interface de usuario
Gestor comunicaciones
UsuarioMóvil
WAP Server
Páginas WML
SQL
XML
- -
Wml binariohttp
13/04/23 UNAP - Ing. Aldo Zanabria 51
Nuevos tipos de dispositivos Variante de los fabricantes BBDD
Navegador
Web Server
Páginas HTML
Lógica de negocio
DatosBase de datos
Interface de usuario
Gestor comunicaciones
UsuarioMóvil
WAP Server
Páginas WML
XML
- -
Wml binariohttp
13/04/23 UNAP - Ing. Aldo Zanabria 52
Nuevos tipos de dispositivos
Variante de los fabricantes pasarelas
Navegador
Web Server
Páginas HTMLLógica de negocio
DatosBase de datos
Interface de usuario
Gestor comunicaciones
UsuarioMóvil
WAP Server
Reglas de traducción WML
SQL
- -
Wml binariohttp
Interface de usuario
13/04/23 UNAP - Ing. Aldo Zanabria 53
Estrategia a seguir
Valorar la durabilidad temporal de las tecnologías a aplicar
Separar, en el diseño e implentación de la aplicación, las capas de lógica de aplicación e interface de usuario
Prestar mucha atención a los nuevos tipos de dispositivos
Examinar con lupa los “atajos” ofrecidos por los fabricantes
13/04/23 UNAP - Ing. Aldo Zanabria 54
Costes sistema distribuido
Elementos a valorar: Coste de las comunicaciones: Valorar alternativas
presentadas por los nuevos proveedores de telecomunicaciones. No descartar el tirar líneas propias
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
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.
13/04/23 UNAP - Ing. Aldo Zanabria 55
Tecnología de objetos distribuidos y
arquitectura de componentes.
13/04/23 UNAP - Ing. Aldo Zanabria 56
Índice
1. Introducción.
2. OMA (Object Management Architecture).
3. CORBA (Common Object Request Broker
Architecture).
4. Conclusiones.
13/04/23 UNAP - Ing. Aldo Zanabria 57
Datos
Introducción
C/S 2 capas
Evolución de la arquitectura de los sistemas informáticos
Sistemas monolíticos
C/S 3 capas
BD
Negocio
PresentaciónNegocio
Presentación
Datos
Negocio
Datos
Negocio
Presentación
13/04/23 UNAP - Ing. Aldo Zanabria 58
BD
Arquitectura multicapa
Presentación
Negocio
Datos
subcapas
13/04/23 UNAP - Ing. Aldo Zanabria 59
Arquitectura de componentes (I)(multicapa y 3-tier)
3:Component system2:Component frameworks
1:Components
Tier 1: Arquitectura de componentes individuales. Tier 2: Arquitectura de los marcos de componentes. Macro-
componentes definidos para realizar una función de negocio concreta.
Tier 3: Arquitectura del sistema de componentes. Super-componente que define todo el sistema.
( tier grada )
13/04/23 UNAP - Ing. Aldo Zanabria 60
Arquitectura de componentes (II)
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.
COMPONENTE = módulo + conjunto de recursos
Módulo = conjunto de clases y puede que elementos de
proceso no orientados a objeto (procedimientos y funciones).
Conjunto de recursos = múltiples interfaces que cada uno
representa un servicio ofrecido por el componente.
COMPONENTE OBJETO
13/04/23 UNAP - Ing. Aldo Zanabria 61
Problemas: 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
Se debe evitar el crecimiento exponencial de interfaces Solución:
Middleware de componentes
Arquitectura de componentes (III)
13/04/23 UNAP - Ing. Aldo Zanabria 62
Arquitectura de componentes (IV)
Alternativas: Sockets.
Implementación costosa. Remote Procedure Calls (RPC).
No soporta objetos explícitamente. Microsoft Distributed Component Object Model (DCOM)
Menos maduro, menos portable y además propietario. Java Remote Method Invocation (RMI)
Solo para JAVA. Common Object Request Broker Architecture (CORBA)
Multiplataforma, multilenguaje, ...
13/04/23 UNAP - Ing. Aldo Zanabria 63
OMA (Object Management Architecture)
OMG: Object Management Group, Inc.http://www.omg.org
Fundado en 1989. Objetivo: Desarrollo de estándares para la reutilización,
portabilidad e interoperabilidad de software orientado a objetos en entornos heterogéneos y distribuidos.
Solución: Definen OMA (Object Management Architecture) de la cual CORBA es una parte.
Historia: 1991: CORBA 1.1 1995: CORBA 2.0 (Modelo de Referencia) 2000: CORBA 2.4 (actual) 2000-2001: CORBA 3.0 (Modelo de Componentes) (en
desarrollo)
13/04/23 UNAP - Ing. Aldo Zanabria 64
OMA: Objetivos técnicos
Transparencia distribución Rendimiento local y
remoto Comportamiento dinámico Sistema de nombrado Consultas: nombre,
atributos, relaciones Control de la concurrencia Transacciones Robustez, disponibilidad
Mantenimiento de versiones
Notificación de eventos Semántica de Relaciones
entre objetos API en C para todas las
operaciones Administración y gestión Internacionalización Estandarización
13/04/23 UNAP - Ing. Aldo Zanabria 65
Arquitectura del modelo de referencia OMA
Application objects
CORBA facilities
Object services (CORBAservices)
CORBA 2.0 Object Request Broker (ORB)
13/04/23 UNAP - Ing. Aldo Zanabria 66
Object services (CORBAservices) (I)
Definen 16 servicios comunes ofrecidos a los objetos: Naming service : Identificación de objetos
Object security service : Servicio de seguridad
Object trader service : Mercader de objetos. Los ofrece a los clientes.
Object transaction service : Permite transacciones con commit-rollback
Change management service : Gestor de versiones de implementación.
Concurrency service : Gestión de bloqueos para permitir concurrencia
Event notification service : Objetos que son mensajes de eventos
Externalization service : Permite copiar objetos por valor
Licensing service : Permite obtener licencias de uso de un objeto
Lifecycle service : Crea, copia, mueve y borra objetos y grupos de objetos
relacionados
13/04/23 UNAP - Ing. Aldo Zanabria 67
Object services (CORBAservices) (II)
Object collections service : Crea colecciones de objetos (basado en
SMALLTALK) (árboles, listas, colas, conjuntos,...)
Object query service : Permite localizar los objetos por el valor de sus atributos
(parecido al Trader, pero en lugar de servicios ofrece atributos)
Persistent object service : Permite al objeto sobrevivir a la terminación del
programa que lo creó
Properties service : Asocia propiedades al objeto (modificable, borrable o sólo
lectura)
Relationship service : Permite relaciones entre objetos
Time service : Soluciona el problema del reloj asíncrono en los SID. Usa time-
stamping.
13/04/23 UNAP - Ing. Aldo Zanabria 68
CORBAfacilities
Definen servicios comunes ofrecidos a las aplicaciones: Horizontales: define colecciones de objetos prefabricados
Interfaz de usuario Gestión de la información Gestión de sistemas Gestión de tareas
Verticales: define servicios comunes para un dominio completo (framework tier)
Objetos de negocio Comercio electrónico Finanzas Manufacturación Medicina Telecomunicaciones
13/04/23 UNAP - Ing. Aldo Zanabria 69
Application objects
Definen servicios específicos de un determinado negocio o aplicación.
Suponen el nivel más alto de los servicios soportados por la arquitectura OMA
13/04/23 UNAP - Ing. Aldo Zanabria 70
CORBA (Common Object Request Broker Architecture)
CORBA es un middleware orientado a objetos / componentes. Los objetos cliente solicitan servicios a los objetos servidor
mediante invocación de método Separa interfaz e implementación Es independiente del lenguaje: los objetos clientes y servidores
se implementan en cualquier lenguaje (de los soportados) Crea transparencia de localización a través del ORB :
de objetos: la invocación siempre se hace en local de red: el ORB la gestiona de activación: los servidores se activan automáticamente de estado persistente: permite que el servidor guarde
persistencia y es transparente al cliente
13/04/23 UNAP - Ing. Aldo Zanabria 71
IDL (Interface Definition Language)
CORBA incorpora un lenguaje de definición de interfaces (IDL)
Independiente del lenguaje de implementación. Mapea hacia los lenguajes de programación habituales. Los ORBs llevan incorporados su traductor de IDL a los
lenguajes de implementación soportados
C C++ AdaJava
IDL
SmallTalk
Object Request Broker (ORB)
Delphi
13/04/23 UNAP - Ing. Aldo Zanabria 72
Comunicación C/S en CORBA
Cliente Servidor
Object Request Broker (ORB)
Invocation Interface
Object Adapter
13/04/23 UNAP - Ing. Aldo Zanabria 73
Object Request Broker (ORB)
Arquitectura de CORBA
DynamicInvocationInterface
IDL Stubs
ORBInterface
IDLStatic
Skeletons
DynamicSkeletonInterface
ObjectAdapter
InterfaceRepository
IDL COMPILERImplementation
Repository
Client Object(Servant)
OBJ REF
operación(args)
resultado(args)
13/04/23 UNAP - Ing. Aldo Zanabria 74
Componentes primarios en CORBA (I)
Object : Entidad de programación CORBA. Tiene una identidad, una interfaz, y una implementación (conocida como
Servant). Servant (sirviente) :
Implementación de una entidad en un lenguaje de programación (en cualquiera de los soportados).
Define las operaciones que soporta un determinado interfaz CORBA IDL. Client :
Entidad de programa que invoca una operación a una implementación de objeto.
Idealmente será tan simple como una invocación a un método. Object Request Broker (ORB) (corredor de peticiones a objetos) :
Núcleo de la arquitectura CORBA. Proporciona transparencia entre los clientes y las implementaciones de los
objetos. 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. Permite conexión con otros ORBs.
13/04/23 UNAP - Ing. Aldo Zanabria 75
Componentes primarios en CORBA (II)
ORB Interface : Interfaz de comunicación con el ORB para solicitarle servicios al propio ORB:
conversión de referencias de objetos a cadenas, ... IDL stubs (cabos) :
El stub es la interfaz que ve el cliente Representante del servidor en el lado cliente (proxy) Realiza invocación remota Define rutinas específicas para operaciones particulares en objetos particulares Definido en IDL y se transforma al lenguaje de programación del Cliente La transformación entre CORBA IDL y el lenguaje de programación se realiza
automáticamente por el IDL compiler IDL skeletons (esqueletos) :
Ofrece una interfaz estática a cada servicio del objeto Definido en IDL y se transforma al lenguaje de programación del Servant
13/04/23 UNAP - Ing. Aldo Zanabria 76
Componentes primarios en CORBA (III)
Dynamic Invocation Interface : Permite la construcción dinámica de invocaciones a objetos. No llama a una rutina específica para una operación particular en un
objeto particular. El cliente especifica el objeto a ser invocado, la operación y el conjunto
de parámetros (esto lo obtiene del Interface Repository) Dynamic Skeleton Interface :
Permite el manejo dinámico de las invocaciones a objetos. No es accedido por un esqueleto específico para una operación
determinada. Se proporciona acceso a través de un nombre de operación y
parámetros.
13/04/23 UNAP - Ing. Aldo Zanabria 77
Componentes primarios en CORBA (IV)
Object Adapter : Conecta al ORB con la implementación del objeto para realizar los
servicios que el ORB proporciona (a otros objetos y clientes): generación e interpretación de referencias a objetos invocación de métodos seguridad de las interacciones activación y desactivación del objeto y su implementación mapeo de las referencias de los objetos a sus implementaciones registro de implementaciones.
13/04/23 UNAP - Ing. Aldo Zanabria 78
Componentes primarios en CORBA (V)
Interface Repository : Almacena información relativa a las interfaces IDL definidas en el Sistema
Distribuido. El ORB solicita los servicios al IR para:
comunicarse con otros ORB de distinta implementación. verificar los parámetros de la petición verificar la existencia de ciclos en los grafos de herencia
Los clientes solicitan los servicios al IR para: navegar por la lista de interfaces facilitar la instalación y distribución de objetos
Un ORB puede tener varios IR según la necesidad (prueba, release, externos, ...
Implementation Repository : Almacena información de administración de cada uno de los objetos: cuáles
están instanciados, como activarlos, permisos, etc.
13/04/23 UNAP - Ing. Aldo Zanabria 79
Conclusiones
Independiente del Sistema Operativo y del lenguaje de programación
Intenta hacer transparente a los programadores todos los aspectos que sea posible.
Facilita la reutilización de software, incluso cuando no esté implementado en un OOL.
Incorpora mecanismos de seguridad: autentificación, encriptación,...
Tecnología OO. Estándar comercial y abierto. CORBA 3.0 Modelo de componentes (CCM)
13/04/23 UNAP - Ing. Aldo Zanabria 80
Seguridad en el SID.INTERNET E INTRANET
13/04/23 UNAP - Ing. Aldo Zanabria 81
OBJETIVOS
Identificar problemas de seguridad en los SID.
Estudiar las características de los cortafuegos y aprender a seleccionarlos.
Funciones de los cortafuegos en Internet e Intranet.
13/04/23 UNAP - Ing. Aldo Zanabria 82
ÍNDICE
1. Riesgos y amenazas.
2. El cortafuegos.
3. Administración de cortafuegos.
4. Políticas de seguridad.
13/04/23 UNAP - Ing. Aldo Zanabria 83
MODELO DE RED CORPORATIVA
INTERNET
Red principalSubred secundaria
Router
Puestos de la subred
ServidorHost
HubRed Ethernet topología bus
Puestos de la red principal
INTRANETAcceso
a Internet
Acceso desde
Internet
13/04/23 UNAP - Ing. Aldo Zanabria 84
FACTORES DE RIESGO
Tipos de activos a proteger (datos confidenciales, programas susceptibles de sufrir sabotajes).
Probabilidad de sufrir un ataque: conocimiento de la posibilidad de existencia de entidades ajenas intrusas.
13/04/23 UNAP - Ing. Aldo Zanabria 85
MECANISMOS PARA LA VALORACIÓN DE RIESGOS
Equipos de “tigres”: ataques simulados. Sesiones creativas de especialistas. Procesos de ingeniería de seguridad de
sistemas: análisis de la arquitectura, identificación de amenazas, integración de la protección.
13/04/23 UNAP - Ing. Aldo Zanabria 86
RIESGOS EN LA INTRANET
Gateway
Host
Hub
Puestos de la red principal
Suplantación delsuperusuario
Suplantaciónde usuarios
Dańos físicos y accesos no autorizados
Ataquesexternos
AGRESIÓN
AGRESIÓN
AGRESIÓN
AGRESIÓN
13/04/23 UNAP - Ing. Aldo Zanabria 87
RIESGOS EN INTERNETINTERNET
Gateway
Host
Hub
Puestos de la red principal
Correo:Captura de mensajesInundaciónInclusión de "Caballos de Troya"
TransferenciasFTP con virus
WWW:Ejecución de programas remotosTransferencias de soft. dudosoAccesos a nuestros datos
AGRESIONES
Aspiración de paquetes
Suplantación de direcciones IPdesde el exterior
PRINCIPAL SOLUCIÓN: CORTAFUEGOS
13/04/23 UNAP - Ing. Aldo Zanabria 88
VALORACIÓN DE RIESGOS Confidencialidad de mis datos.
Atractivo de activos. Características de mi
conexión Internet. Características de mis
routers.
Presupuesto de seguridad.
Uso de la criptografía. Valorar el nivel de
nuestro personal informático.
13/04/23 UNAP - Ing. Aldo Zanabria 89
EL CORTAFUEGOS
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.
Función principal: limitar acceso a la Intranet filtrando los paquetes entrantes (por medio de la información que contienen).
13/04/23 UNAP - Ing. Aldo Zanabria 90
CARACTERÍSTICAS DEL CORTAFUEGOS Registro de actividades: información de
sesiones (paquetes, fecha). Sistema de aviso de intrusiones. Ubicado de tal forma que las
comunicaciones pasen a través suyo.
13/04/23 UNAP - Ing. Aldo Zanabria 91
UBICACIÓN DE CORTAFUEGOS
INTERNET
Red principalSubred secundaria
Router
Puestos de la subred
ServidorHost
HubRed Ethernet topología bus
Puestos de la red principal
INTRANETAcceso
a Internet
Acceso desde
Internet
Cortafuegos
Cortafuegos Cortafuegos
13/04/23 UNAP - Ing. Aldo Zanabria 92
TIPOS DE CORTAFUEGOS
Filtrado de paquetes: generalmente, routers. Se hace a nivel de red (poco seguros).
Gateways a nivel de aplicación: programas. Las conexiones se canalizan a través de aplicaciones proxy.
Híbridos: combina los dos anteriores. Host bastión: arquitectura más que tipo de
cortafuegos. Aisla la LAN.
13/04/23 UNAP - Ing. Aldo Zanabria 93
¿CÓMO SE FILTRAN LOS PAQUETES? Se especifican reglas de filtrado, y acciones
asociadas a ellas. En ellas consta: número de regla, dirección
origen, destino, protocolo, puerto origen y destino y acción.
Importante: el orden de las reglas.
13/04/23 UNAP - Ing. Aldo Zanabria 94
FILTROS SOFTWARE
Filtrado de sesiones: se realiza generalmente
en el kernel del S.O. Una sola regla para cada
sesión.
Aplicaciones Proxy: programas que se sitúan
en el cortafuegos y actúan en representación del usuario.
Conexiones: directa, cliente modificado y proxy invisible.
Desventaja: una aplicación por servicio
13/04/23 UNAP - Ing. Aldo Zanabria 95
AUTENTIFICACIÓN DE USUARIOS
Contraseñas: un solo uso (cambia cada sesión por algoritmos criptográficos) y uso múltiple (pueden ser “pinchadas”).
Tarjetas inteligentes o llaves (autentificadores manuales): se solicita palabra de paso y clave, y se devuelve contraseña.
Huellas dactilares y modelos de retina. Problema de todos ellos: secuestros de sesión.
Solución: autentificación de paquetes.
13/04/23 UNAP - Ing. Aldo Zanabria 96
ADMINISTRACIÓN DEL CORTAFUEGOS Mantener las cuentas
de usuarios. Actualizar permisos de
acceso a hosts. Reaccionar ante
alarmas. Revisar registros de
actividad.
Hacer copias de seguridad de los datos del cortafuegos.
Mantenimiento del sistema del cortafuegos.
Información sobre tecnología de ataques.
13/04/23 UNAP - Ing. Aldo Zanabria 97
TRAMPAS Y CEBOS
Sirven para atraer atacantes sospechosos. Determinar tipos de acceso intrusos. Crear entorno ficticio y legal (avisar al
usuario que está accediendo a la red). Obtener información para demandar al
atacante (tener cuidado con no transgredir la ley nosotros).
13/04/23 UNAP - Ing. Aldo Zanabria 98
RESPUESTA A UN ATAQUE (1)
Mantener la calma (normalmente es inofensivo).
¿Interrumpimos el ataque?. Sí: destruir la conexión y desconectar el
cortafuegos. No: detectar al intruso (leer registro de
auditoría, obtener lista de routers hasta el intruso, identificar usuarios actuales).
13/04/23 UNAP - Ing. Aldo Zanabria 99
RESPUESTA A UN ATAQUE (Y 2)
Una vez finalizado el ataque: Determinar los cambios a efectuar en la
política de seguridad. Documentar detalles del ataque. Informar al proveedor del cortafuegos, y a las
autoridades (si procede).
13/04/23 UNAP - Ing. Aldo Zanabria 100
POLÍTICA DE SEGURIDAD
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.
13/04/23 UNAP - Ing. Aldo Zanabria 101
TIPOS DE POLÍTICAS DE SEGURIDAD Política de acceso en el ámbito de los
servicios: define los requisitos de control de acceso a usuarios. (Alto nivel).
Política de acceso en el ámbito de implementación de la red: definición de las reglas de filtrado del cortafuegos. (Bajo nivel).
13/04/23 UNAP - Ing. Aldo Zanabria 102
POSIBLES PROBLEMAS
Suponen un retraso en la implantación de las protecciones en la red.
Burocracia: entran en los trabajos cotidianos de operación del sistema.
Hay que velar por el cumplimiento de la política para que sea efectiva.
13/04/23 UNAP - Ing. Aldo Zanabria 103
REQUISITOS PARA UNA CORRECTA POLÍTICA Determinar permisos para servicios de
entrada (TELNET, correo etc.) Determinar permisos para servicios de salida
(WWW, FTP etc.) Determinar requisitos de auditoría:
disminuyen rendimiento de la red. Elegir herramienta de administración. Requisitos para cebos y trampas: no salirse
de la ley.
13/04/23 UNAP - Ing. Aldo Zanabria 104
EJEMPLO (1)
Propuesto por Ed Amoroso y Ron Sharp.
a) Puntos principales de contacto (personas).
b) Registro de modificaciones (versiones de la política).
c) Ámbito de los requisitos: definición de la red.
13/04/23 UNAP - Ing. Aldo Zanabria 105
EJEMPLO (Y 2)
d) Clasificación de la información de la empresa (abierta, propietaria y propietaria restringida).
e) Clasificación de las redes de la empresa: abierta, propietaria y propietaria - restringida.
f) Servicios del cortafuegos: acceso o no a Telnet, FTP, EMAIL, WWW.
13/04/23 UNAP - Ing. Aldo Zanabria 106
REAL DECRETO 994/1999, de 11 de
junio (B.O.E. 25.06.1999) http://www.igsap.map.es:80/cia/dispo/rd994-99.htm Establece 3 niveles de seguridad:
a) BÁSICO: datos de carácter personal
b) INTERMEDIO: datos de infracciones administrativas, penales, servicios financieros, o personales que permitan evaluación de personalidad del individuo.
c) ALTO: datos de ideología, religión, creencias, raza, salud, vida sexual y política.
13/04/23 UNAP - Ing. Aldo Zanabria 107
REAL DECRETO 994/1999. Requisitos
Nivel BÁSICO: Documento de seguridad con la normativa básica. Mecanismos de actualización y revisión de la normativa. Documento de funciones y obligaciones del personal. Medidas para informar al personal sobre la normativa. Registro de incidencias. Relación de usuarios y procedimientos de identificación y autentificación. Renovación periódica de contraseñas y almacenamiento ininteligible. Mecanismos para evitar intrusiones no autorizadas. Control de soportes (inventario). Control de salidas de soportes. Copias de respaldo, al menos semanalmente.
13/04/23 UNAP - Ing. Aldo Zanabria 108
REAL DECRETO 994/1999. Requisitos (2) Nivel INTERMEDIO: Todo el básico. Documento de seguridad ampliado. Designación de responsables de seguridad. Consignación de recuperaciones en incidencias. Autorización escrita del responsable para recuperar ficheros. Identificación unívoca de usuarios. Limitación de accesos no autorizados reincidentes. Control de acceso físico. Registro de entrada y salida de soportes. Mecanismo para impedir recuperaciones de información almacenada en
soportes. Auditorías informáticas cada 2 años. Pruebas con datos ficticios.
13/04/23 UNAP - Ing. Aldo Zanabria 109
REAL DECRETO 994/1999. Requisitos (y 3)
Nivel ALTO: Todo el intermedio. Copias de respaldo y recuperación fuera de las instalaciones
de equipos informáticos. Cifrado de la información de los soportes. Registro de accesos. Informe mensual de revisiones y problemas detectados. Transmisión cifrada de datos.
top related