Sistemas de información distribuidos

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


Arquitectura Cliente/Servi

dor


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.


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.


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


¿Cuándo implantar C/S?

Cambios estructurales y organizativos. Cambios en organigramas. Respuesta dinámica de mercado. Cambio en procesos de negocio.


¿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.


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.


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.


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.


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.


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.


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.


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.


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.


Evolución (III)

EL FUTURO. Facilidad de uso de las aplicaciones. Accesos a datos distribuidos en cualquier lugar del mundo

(y del espacio).


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.


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.


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.


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


Modelos C/S (II)

Función distribuida Máxima flexibilidad. Lógicas de negocio separadas.

Presentación Negocio DatosNegocio

C S


Modelos C/S (III)

Datos distribuidos Ficheros distribuidos. Bases de datos distribuidas.

Presentación Negocio Datos

C S


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.


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


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”


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.


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.


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.


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.


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.


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.


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.


Ejercicios:


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?


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é?


CONSIDERACIONES:

Aspectos a considerar, tendencias, Desarrollo web, nuevos tipos de dispositivos.


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


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



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.



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



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 (**)



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



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


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


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


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


Desarrollos Web

Esquema general Navegador

Web Server

ServletMáquina virtual

Java

ConectorCORBA

ServidorCORBA

Procesos CGI

HTTP

Parámetrosproceso

CORBA

RMIBase de datos


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


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


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


Nuevos tipos de dispositivos Variante de los fabricantes BBDD

Navegador

Web Server

Páginas HTML

Lógica de negocio

DatosBase de datos



UsuarioMóvil

WAP Server

Páginas WML

XML

- -

Wml binariohttp


Nuevos tipos de dispositivos

Variante de los fabricantes pasarelas

Navegador

Web Server

Páginas HTMLLógica de negocio

DatosBase de datos



UsuarioMóvil

WAP Server

Reglas de traducción WML

SQL

- -

Wml binariohttp



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


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.


Tecnología de objetos distribuidos y

arquitectura de componentes.


Índice

1. Introducción.

2. OMA (Object Management Architecture).

3. CORBA (Common Object Request Broker

Architecture).

4. Conclusiones.


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


BD

Arquitectura multicapa

Presentación

Negocio

Datos

subcapas


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 )


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


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)


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, ...


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)


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


Arquitectura del modelo de referencia OMA

Application objects

CORBA facilities

Object services (CORBAservices)

CORBA 2.0 Object Request Broker (ORB)


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


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.


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


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


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


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


Comunicación C/S en CORBA

Cliente Servidor


Invocation Interface

Object Adapter



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)


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.


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


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.


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.


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.


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)


Seguridad en el SID.INTERNET E INTRANET


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.


ÍNDICE

1. Riesgos y amenazas.

2. El cortafuegos.

3. Administración de cortafuegos.

4. Políticas de seguridad.


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


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.


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.


RIESGOS EN LA INTRANET

Gateway

Host

Hub


Suplantación delsuperusuario

Suplantaciónde usuarios

Dańos físicos y accesos no autorizados

Ataquesexternos

AGRESIÓN

AGRESIÓN

AGRESIÓN

AGRESIÓN


RIESGOS EN INTERNETINTERNET

Gateway

Host

Hub


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


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.


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).


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.


UBICACIÓN DE CORTAFUEGOS

INTERNET

Red principalSubred secundaria

Router

Puestos de la subred

ServidorHost

HubRed Ethernet topología bus


INTRANETAcceso

a Internet

Acceso desde

Internet

Cortafuegos

Cortafuegos Cortafuegos


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.


¿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.


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


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.


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.


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).


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).


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).


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.


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).


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.


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.


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.


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.


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.


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.


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.


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.

Sistemas de información distribuidos

Documents

Transcript of Sistemas de información distribuidos